Re: should there be a hard-limit on the number of transactions pending undo?

From: Andres Freund <andres(at)anarazel(dot)de>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: should there be a hard-limit on the number of transactions pending undo?
Date: 2019-07-19 20:14:38
Message-ID: 20190719201438.32g3cc444czmmxtz@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2019-07-19 15:57:45 -0400, Robert Haas wrote:
> On Fri, Jul 19, 2019 at 3:12 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > Isn't that pretty inherently required? How are otherwise ever going to
> > be able to roll back a transaction that holds an AEL on a relation it
> > also modifies? I might be standing on my own head here, though.
>
> I think you are. If a transaction holds an AEL on a relation it also
> modifies, we still only need something like RowExclusiveLock to roll
> it back. If we retain the transaction's locks until undo is complete,
> we will not deadlock, but we'll also hold AccessExclusiveLock for a
> long time. If we release the transaction's locks, we can perform the
> undo in the background with only RowExclusiveLock, which is full of
> win. Even you insist that the undo task should acquire the same lock
> the relation has, which seems entirely excessive to me, that hardly
> prevents undo from being applied. Once the original transaction has
> released its locks, those locks are released, and the undo system can
> acquire those locks the next time the relation isn't busy (or when it
> gets to the head of the lock queue).

Good morning, Mr Freund. Not sure what you were thinking there.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-07-19 20:29:25 Re: sepgsql seems rather thoroughly broken on Fedora 30
Previous Message Robert Haas 2019-07-19 19:57:45 Re: should there be a hard-limit on the number of transactions pending undo?