Issue in current XactLockTableWait, starting with 3c27944fb2141,
discovered while reviewing https://commitfest.postgresql.org/40/3806/
Test demonstrating the problem is 001-isotest-tuplelock-subxact.v1.patch
A narrative description of the issue follows:
session1 - requests multiple nested subtran
On Mon, Nov 28, 2022 at 10:28 AM Simon Riggs
wrote:
> So we have these options
>
> 1. Removing the XactLockTableDelete() call in CommitSubTransaction().
> That releases lock waiters earlier than expected, which requires
> pushups in XactLockTableWait() to cope with that (which are currently
> brok
On 2022-Nov-28, Simon Riggs wrote:
> A narrative description of the issue follows:
> session1 - requests multiple nested subtransactions like this:
> BEGIN; ...
> SAVEPOINT subxid1; ...
> SAVEPOINT subxid2; ...
> However, if subxid2 subcommits, then the lock wait moves from subxid2
> to the topxi
On Mon, 28 Nov 2022 at 18:53, Alvaro Herrera wrote:
>
> On 2022-Nov-28, Simon Riggs wrote:
>
> > A narrative description of the issue follows:
> > session1 - requests multiple nested subtransactions like this:
> > BEGIN; ...
> > SAVEPOINT subxid1; ...
> > SAVEPOINT subxid2; ...
>
> > However, if s
On Mon, 28 Nov 2022 at 17:38, Robert Haas wrote:
>
> On Mon, Nov 28, 2022 at 10:28 AM Simon Riggs
> wrote:
> > So we have these options
> >
> > 1. Removing the XactLockTableDelete() call in CommitSubTransaction().
> > That releases lock waiters earlier than expected, which requires
> > pushups in
On Mon, Nov 28, 2022 at 2:45 PM Simon Riggs
wrote:
> An easy point to confuse:
> "subtransaction to end": The subtransaction is "still running" to
> other backends even AFTER it has been subcommitted, but its state now
> transfers to the parent.
>
> So the subtransaction doesn't cease running unti
Robert Haas writes:
> That's not what "running" means to me. Running means it's started and
> hasn't yet committed or rolled back.
A subxact definitely can't be considered committed until its topmost
parent commits. However, it could be known to be rolled back before
its parent. IIUC, the curre
On Mon, Nov 28, 2022 at 3:01 PM Tom Lane wrote:
> One thing we need to be pretty careful of here is to not break the
> promise of atomic commit. At topmost commit, all subxacts must
> appear committed simultaneously. It's not quite clear to me whether
> we need a similar guarantee in the rollbac
On Mon, 28 Nov 2022 at 21:10, Robert Haas wrote:
>
> On Mon, Nov 28, 2022 at 3:01 PM Tom Lane wrote:
> > One thing we need to be pretty careful of here is to not break the
> > promise of atomic commit. At topmost commit, all subxacts must
> > appear committed simultaneously. It's not quite clea
