On Thu, Oct 2, 2008 at 12:51 PM, Aidan Van Dyk <[EMAIL PROTECTED]> wrote: >> > But I thought you didn't really care about hint-bit updates, even in the >> > current strategy... but I'm fully ignorant about the code, sorry... >> >> The current implementation does not take it into account. > > So if PG currently doesn't care about the hit-bits being updated, during > the write, then why should introducing a double-buffer introduce the a > torn-page problem Tom mentions? I admit, I'm fishing for information > from those in the know, because I haven't been looking at the code long > enough (or all of it enough) to to know all the ins-and-outs...
PG doesn't care because during hint-bits aren't logged and during normal WAL replay, the old page will be pulled from the WAL. I believe what Tom is referring to is that the buffer PG sends to write() can still be modified by way of SetHintBits between the time smgrwrite is called and the time the actual write takes place, which is why we can't rely on a checksum of the buffer pointer passed to smgrwrite and friends. If we're double-buffering the write, I don't see where we could be introducing a torn-page, as we'd actually be writing a copied version of the buffer. Will look into this. -- Jonah H. Harris, Senior DBA myYearbook.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
