Excerpts from Robert Haas's message of mar nov 09 16:05:57 -0300 2010: > And it still allows silent data corruption, because bogusly clearing a > hint bit is, at the moment, harmless, but bogusly setting one is not. > I really have to wonder how other products handle this. PostgreSQL > isn't the only database product that uses MVCC - not by a long shot - > and the problem of detecting whether an XID is visible to the current > snapshot can't be ours alone. So what do other people do about this? > They either don't cache the information about whether the XID is > committed in-page (in which case, are they just slower or do they have > some other means of avoiding the performance hit?) or they cache it in > the page (in which case, they either WAL log it or they don't checksum > it). I mean, there aren't any other options, are there?
Maybe allocate enough shared memory for pg_clog buffers back to the freeze horizon, and just don't use hint bits? Maybe some intermediate solution, i.e. allocate a large bunch of pg_clog buffers, and do WAL-logged setting of hint bits only for tuples that go further back. I remember someone had a patch to set all the bits in a page that passed a threshold of some kind. Ah, no, that was for freezing tuples. -- Álvaro Herrera <alvhe...@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
