Re: Multiple table entries?

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.

--
greg
http://mit.edu/~gsstark/resume.pdf

In response to

Responses

Browse pgsql-general by date

  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?