Alvaro Herrera <alvhe...@commandprompt.com> writes:
> Excerpts from Tom Lane's message of sáb ene 28 01:35:33 -0300 2012:
>> This is the same thing I was complaining about in the bug #6123 thread,
>> http://archives.postgresql.org/message-id/9698.1327266...@sss.pgh.pa.us
> Hm. Okay, I hadn't read that.
> In my FOR KEY SHARE patch I have added a heap_lock_updated_tuple that
> makes heap_lock_tuple follow the update chain forward when the tuple
> being locked is being updated by a concurrent transaction.
Um, we do that already, no? Certainly in READ COMMITTED queries, we
will do so, though it happens at a higher level than heap_lock_tuple.
> I haven't traced through FETCH to see if it makes sense to apply some
> of that to it.
The issue here is what to do when the update came from our *own*
transaction. In particular I'm a bit worried about avoiding what the
code calls the Halloween problem, namely an infinite loop of re-updating
the same tuple if the scan keeps coming across newer versions.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
