Excerpts from Robert Haas's message of mar sep 20 16:04:03 -0300 2011: > On Tue, Sep 20, 2011 at 2:28 PM, Heikki Linnakangas > <heikki.linnakan...@enterprisedb.com> wrote: > > On 20.09.2011 20:42, Alvaro Herrera wrote: > >> I notice that heap_update releases the buffer lock, after checking the > >> HeapTupleSatifiesUpdate result, and before marking the tuple as updated, > >> to pin the visibility map page -- heapam.c lines 2638ff in master branch. > >> > >> Is this not a bug? I imagine that while this code releases the lock, > >> someone else could acquire it and grab a FOR SHARE lock on the tuple; if > >> the update later ends up modifying the tuple completely, this could > >> cause an FK to be broken, for example. > > > > Yeah, I think you're right. Not only might someone grab a FOR SHARE lock on > > the tuple, but someone might even update it under your nose. > > Yeah, I think he's right, too. :-( > > The easiest fix seems to be (as you suggest) to add "goto l2" after > reacquiring the lock. Can we get away with (and is there any benefit > to) doing that only if xmax has changed?
Hmm ... I think that works, and it would suit my purposes too. Note this means you have to recheck infomask too (otherwise consider that IS_MULTI could be set the first time, and not set the second time, and that makes the Xmax have a different meaning.) OTOH if you just do it always, it is simpler. -- Á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
