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 <alvhe...@alvh.no-ip.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 <alvhe...@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
