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.
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? |