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