Amit Kapila wrote: > On Sat, Jul 15, 2017 at 2:30 AM, Alvaro Herrera > <alvhe...@2ndquadrant.com> wrote:
> > a transaction wants to lock the > > updated version of some tuple, and it does so; and some other > > transaction is also locking the same tuple concurrently in a compatible > > way. So both are okay to proceed concurrently. The problem is that if > > one of them detects that anything changed in the process of doing this > > (such as the other session updating the multixact to include itself, > > both having compatible lock modes), it loops back to ensure xmax/ > > infomask are still sane; but heap_lock_updated_tuple_rec is not prepared > > to deal with the situation of "the current transaction has the lock > > already", so it returns a failure and the tuple is returned as "not > > visible" causing the described problem. > > Your fix seems logical to me, though I have not tested it till now. > However, I wonder why heap_lock_tuple need to restart from the > beginning of update-chain in this case? Well, it's possible that we could change things so that it doesn't need to re-start from the same spot where it initially began, but I think it requires changing too much code; I'd rather not touch it in a back-patchable bug fix. If we really wanted, we could perhaps change things to avoid repeated walks of the chain, but I'd see that as a pg11 (or future) change only. (You would be forgiven for thinking that the interactions between EvalPlanQualFetch, heap_lock_tuple and heap_lock_update_tuple are rather Rube Goldbergian, to use Tom's term.) -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, 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