On 2012-11-30 18:09:49 +0530, Pavan Deolasee wrote: > On Fri, Nov 30, 2012 at 5:28 PM, Andres Freund <and...@2ndquadrant.com>wrote: > > > > > > > > > > That seems to be safe to me. Anything thats been read above can't really > > > change. The tuple is already locked, so a concurrent update/delete has to > > > wait on us. We have a pin on the buffer, so VACUUM or HOT-prune can't > > > happen either. I can't see any other operation that can really change > > those > > > fields. > > > > We only get the pin right there, I don't see any preexisting pin. Which > > means we might have just opened a page thats in the process of being > > pruned/vacuumed by another backend. > > > > Hmm. Yeah, you're right. That is a possible risky scenario. Even though > cleanup lock waits for all pins to go away, it will work only if every > reader takes at least a SHARE lock unless it was continuously holding a pin > on a buffer (in which case its OK to drop lock and read a tuple body > without reacquiring it again). Otherwise, as you rightly pointed out, we > could actually be reading a page which being actively cleaned up and tuples > are being moved around.
Well, live (or recently dead) tuples can't be just moved arround unless I miss something. That would cause problems with with HeapTuples directly pointing into the page as youve noticed. > > I think a concurrent heap_(insert|update)/PageAddItem might actually be > > already dangerous because it might move line pointers around > > > > > I don't we move the line pointers around ever because the indexes will be > pointing to them. The indexes point to a tid, not to a line pointer. So reshuffling the linepointer array - while keeping the tids valid - is entirely fine. Right? Also, PageAddItem does that all the time, so I think we would have noticed if not ;) Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers