Re: BUG #15977: Inconsistent behavior in chained transactions - Mailing list pgsql-bugs

From fn ln
Subject Re: BUG #15977: Inconsistent behavior in chained transactions
Date
Msg-id CA+99BHqXfKP=vbX4DmuGY3O8NP+nv-hu-fKLV6JgYj7-COE3CQ@mail.gmail.com
Whole thread Raw
In response to Re: BUG #15977: Inconsistent behavior in chained transactions  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: BUG #15977: Inconsistent behavior in chained transactions  (Fabien COELHO <coelho@cri.ensmp.fr>)
Re: BUG #15977: Inconsistent behavior in chained transactions  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-bugs
COMMIT AND CHAIN in implicit block leaves blockState as TBLOCK_STARTED, which doesn't trigger the chaining.
but ROLLBACK AND CHAIN sets the blockState into TBLOCK_ABORT_PENDING, so the chaining is triggered.

I think disabling s->chain beforehand should do the desired behavior.

2019年8月25日(日) 18:11 Fabien COELHO <coelho@cri.ensmp.fr>:

> The following bug has been logged on the website:
>
> Bug reference:      15977
> Logged by:          mtlh kdvt
> Email address:      emuser20140816@gmail.com
> PostgreSQL version: 12beta3
> Operating system:   Windows
> Description:
>
> When a ROLLBACK AND CHAIN command is executed in the implicit transaction
> block, a new transaction will be started:
>   db=# ROLLBACK AND CHAIN;
>   WARNING:  there is no transaction in progress
>   ROLLBACK
>   db=# ROLLBACK AND CHAIN;
>   ROLLBACK
>
> However, a COMMIT AND CHAIN command won't start a new transaction:
>   db=# COMMIT AND CHAIN;
>   WARNING:  there is no transaction in progress
>   COMMIT
>   db=# COMMIT AND CHAIN;
>   WARNING:  there is no transaction in progress
>   COMMIT

Thanks for the report.

Indeed, I confirm, and I should have caught this one while reviewing…

Doc says:

"If AND CHAIN is specified, a new transaction is immediately started with
the same transaction characteristics as the just finished one. Otherwise,
no new transaction is started."

If there is no transaction in progress, the spec is undefined. Logically,
ITSM that there should be no tx reset if none was in progress, so ROLLBACK
has the wrong behavior?

A quick glance at the code did not yield any obvious culprit, but maybe
I'm not looking at the right piece of code.

Doc could happend ", if any" to be clearer.

--
Fabien.
Attachment

pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #15982: in v11.5, you cannot script existing views
Next
From: "Jungle Boogie"
Date:
Subject: Re: BUG #15964: vacuumdb.c:187:10: error: use of undeclaredidentifier 'FD_SETSIZE'