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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
