Re: cursors FOR UPDATE don't return most recent row

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Excerpts from Tom Lane's message of sb 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.1327266271@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