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:12:07 |
Message-ID: | 407d949e0908231112y17ded3eoc0f6ea132453a1cb@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sun, Aug 23, 2009 at 7:00 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Greg Stark <gsstark(at)mit(dot)edu> writes:
>> The last tuple is marked strangely I think. I don't think it's
>> supposed to have XMAX_INVALID if xmax is 0 but I could be wrong. Also,
>> I don't understand why it's marked as UPDATED if ctid and xmax aren't
>> set.
>
> No, that all looks right to me. UPDATE sets HEAP_UPDATED on the newer
> version of the row, not the older one. What looks interesting to me is
> that the last update isn't marked HEAP_ONLY_TUPLE, ie, it's not in the
> same HOT chain. Why is that I wonder ...
>
>> I'm wondering if the page allvisible flag is set. The visibility map
>> is one of the few 8.4 patches which impact transaction visibility.
>
> 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Jahnke | 2009-08-23 18:14:01 | Re: bytea corruption? |
Previous Message | Tom Lane | 2009-08-23 18:00:38 | Re: Multiple table entries? |