Re: HeapTupleSatisfiesToast not setting XMIN_COMMITTED?

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: HeapTupleSatisfiesToast not setting XMIN_COMMITTED?
Date: 2011-09-21 19:14:15
Message-ID: 1316632156-sup-8888@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Excerpts from Merlin Moncure's message of mié sep 21 16:02:34 -0300 2011:
> On Wed, Sep 21, 2011 at 1:03 PM, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> >
> > Hi,
> >
> > I notice that HeapTupleSatisfiesToast is not setting the
> > HEAP_XMIN_COMMITTED bit, though it is reading it.  Is there a reason for
> > this?  It seems to me that it'd make sense to have it set ... unless
> > it's set by some other routine, somehow?
>
> I think it's implied from the untoasted row. Notice that it's not
> checking visibility either except in binary upgrade cases.

Yeah, so toast visibility is highly dependant to the referencing row.
Which makes sense. But then, if the XMIN_COMMITTED bit is not set,
you're forced to check the other bits every time. I guess the tradeoff
is that if you set it, the page is dirtied and you're forced to write it
down, which is even worse.

More interesting, however, is the fact that the XMAX_COMMITTED bit is
never set either. I guess the rows are deleted by a different mechanism
(tuptoaster probably) -- it isn't obvious how this works just by looking
at tqual.c. It seems to do nothing at all.

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2011-09-21 19:21:38 Re: Inlining comparators as a performance optimisation
Previous Message Robert Haas 2011-09-21 19:08:29 Re: memory barriers (was: Yes, WaitLatch is vulnerable to weak-memory-ordering bugs)