On 2019-07-19 15:57:45 -0400, Robert Haas wrote: > On Fri, Jul 19, 2019 at 3:12 PM Andres Freund <and...@anarazel.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.
