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.linnakangas@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 <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
