On Sun, Aug 23, 2009 at 7:34 PM, Tom Lane<tgl@xxxxxxxxxxxxx> wrote: > Greg Stark <gsstark@xxxxxxx> writes: >> On Sun, Aug 23, 2009 at 7:00 PM, Tom Lane<tgl@xxxxxxxxxxxxx> wrote: >>> But we don't use that while examining individual tuples, do we? > >> We don't use the visibility map itself but we *do* use the page >> header's all visible bit. On a sequential scan we skip the visibility >> check for tuples on the page if the page header bit is set. > > Urgh. I bet that's where the problem is then. Some path is failing > to clear that bit, or maybe there's a race condition that allows it > to become set incorrectly (ie right after somebody else adds a tuple). Well it only gets set in vacuum when we have the vacuum cleanout lock so I can't see it getting set incorrectly unless there's a simple logic error in vacuum. I just scanned it and it looks right to me. I can imagine it failing to be unset. Or being unset but allowing a race condition window before it's unset when it's wrong. That doesn't explain why it the HEAP_ONLY_TUPLE flag would be missing though. Also, vacuum logs a warning if the flag is found to be set and shouldn't be. I suppose that could easily be missed though if it's autovacuum that ran it. Also, the flag might fail to be cleared but then be cleared later by another operation. I wonder how much damage it can do while it's wrong. -- greg http://mit.edu/~gsstark/resume.pdf -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
