From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jeff Ross <jross(at)wykids(dot)org>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Multiple table entries? |
Date: | 2009-08-23 18:42:31 |
Message-ID: | 407d949e0908231142g48bf45aapdc1bc71550708a@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sun, Aug 23, 2009 at 7:34 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Greg Stark <gsstark(at)mit(dot)edu> writes:
>> On Sun, Aug 23, 2009 at 7:00 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-08-23 19:51:08 | Re: Multiple table entries? |
Previous Message | Tom Lane | 2009-08-23 18:34:02 | Re: Multiple table entries? |