| From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
|---|---|
| To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
| Cc: | Gregory Stark <stark(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Stark <greg(dot)stark(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Block-level CRC checks |
| Date: | 2008-11-12 20:24:41 |
| Message-ID: | 20081112202441.GK4535@alvh.no-ip.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Martijn van Oosterhout wrote:
> On Wed, Nov 12, 2008 at 11:08:13AM -0300, Alvaro Herrera wrote:
> > However, your idea suggests something else that we could do to improve
> > the patch: skip the ItemId->lp_flags during the CRC calculation. This
> > would mean we wouldn't need to WAL-log those. The problem with that is
> > that lp_flags are only 2 bits, so we would need to iterate zeroing them
> > and restore them after CRC_COMP() instead of simply skipping.
>
> Not sure why you're so intent on actually changing memory just so you can use
> COMP_CRC32, which is just a for loop around the COMP_CRC32_ONE I
> mentioned. Actually changing the memory probably means locking so why
> bother.
Well, that's one of the problems -- memory is being changed without
holding a lock. The other problem is that of pages being changed, their
CRCs calculated, and then a crash occuring. On recovery, the CRC is
restored but some of those changed bits are not.
The other thing that maybe you didn't notice is that lp_flags are 2
bits, not a full byte. A byte-at-a-time CRC calculation is no help
there.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gregory Stark | 2008-11-12 20:38:33 | Re: Block-level CRC checks |
| Previous Message | Martijn van Oosterhout | 2008-11-12 20:16:09 | Re: Block-level CRC checks |