On 2016-08-10 11:01 PM, Alvaro Herrera wrote:
Oh, I see ... so there's an update chain, and you're updating a earlier
tuple. But the later tuple has a multixact and one of the members is
the current transaction.
I wonder how can you lock a tuple that's not the latest, where that
update chain was produced by your own transaction. I suppose this is
because of plpgsql use of cursors.
There's a rolled back subtransaction that also did some magic on the
rows AFAICT. I can try and spend some time producing a smaller test
case over the weekend. No hurry since this missed the today's point
release anyway.
.m
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
