Re: BUG #15977: Inconsistent behavior in chained transactions

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: fn ln <emuser20140816(at)gmail(dot)com>
Cc: PostgreSQL Bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #15977: Inconsistent behavior in chained transactions
Date: 2019-08-29 06:30:07
Message-ID: alpine.DEB.2.21.1908290815110.28828@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers


Hello,

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

Patch applies with "patch", although "git apply" complained because of
CRLF line terminations forced by the octet-stream mime type.

Patch compiles cleanly. Make check ok.

Patch works for me, and solution seems appropriate. It should be committed
for pg 12.0.

There could be a test added in "regress/sql/transactions.sql", I'd suggest
something like:

-- implicit transaction and not chained.
COMMIT AND CHAIN;
COMMIT;
ROLLBACK AND CHAIN;
ROLLBACK;

which should show the appropriate "no transaction in progress" warnings.

Doc could be made a little clearer about what to expect when there is no
explicit transaction in progress.

--
Fabien.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Mikael Kjellström 2019-08-29 07:09:14 Re: BUG #15964: vacuumdb.c:187:10: error: use of undeclared identifier 'FD_SETSIZE'
Previous Message Michael Paquier 2019-08-29 00:00:20 Re: BUG #15964: vacuumdb.c:187:10: error: use of undeclared identifier 'FD_SETSIZE'

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2019-08-29 07:24:11 Re: BUG #15977: Inconsistent behavior in chained transactions
Previous Message Fabien COELHO 2019-08-29 06:14:54 Re: refactoring - share str2*int64 functions