| 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: | Whole Thread | Raw Message | 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.
| 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' | 
| 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 |