Re: BUG #15977: Inconsistent behavior in chained transactions

From: fn ln <emuser20140816(at)gmail(dot)com>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Andres Freund <andres(at)anarazel(dot)de>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #15977: Inconsistent behavior in chained transactions
Date: 2019-09-07 16:32:17
Message-ID: CA+99BHonWhp7OcbGdc+0_mvO3T+ktf9roqWCn4OC0OpRr+Z3MA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

> Missed them somehow. But I don't think they're quite sufficient. I think
> at least we also need tests that test things like multi-statement
> exec_simple-query() *with* explicit transactions and chaining.
Added a few more tests for that.

> Now, I'd prefer error in all cases, no doubt about that, which might be
> considered a regression. A way around that could be to have a GUC decide
> between a strict behavior (error) and the old behavior (warning).
I think it's more better to have a GUC to disable implicit transaction
'block' feature, because that's probably the root of all issues.

2019年9月7日(土) 22:23 Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>:

>
> > I made another patch for that.
> > I don't have much confidence with my English spelling so further
> > improvements may be needed.
> >
> >> If it is too much a change and potential regression, then I think that
> the
> >> "and chain" variants should be consistent and just raise warnings.
>
> > We don't have an exact answer for implicit transaction chaining behavior
> > yet.
>
> > So I think it's better to disable this feature until someone discovers
> the
> > use cases for this.
>
> > Permitting AND CHAIN without a detailed specification might cause
> troubles
> > in future.
>
> I think that it would be too bad to remove this feature for a small
> implementation-dependent corner case.
>
> Documentation says that COMMIT/ROLLBACK [AND CHAIN] apply to the "current
> transaction", and "BEGIN initiates a transaction block".
>
> If there is no BEGIN, there is no "current transaction", so basically the
> behavior is unspecified, whether AND CHAIN or not, and we are free
> somehow.
>
> In such case, I'm simply arguing for consistency: whatever the behavior,
> the chain and no chain variants should behave the same.
>
> Now, I'd prefer error in all cases, no doubt about that, which might be
> considered a regression. A way around that could be to have a GUC decide
> between a strict behavior (error) and the old behavior (warning).
>
> --
> Fabien.
>

Attachment Content-Type Size
disable-implicit-transaction-chaining-v6.patch application/octet-stream 9.2 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Fabien COELHO 2019-09-07 17:04:38 Re: BUG #15977: Inconsistent behavior in chained transactions
Previous Message Renato Netto 2019-09-07 15:39:20 erro in Instaling PostegreSQL 11

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2019-09-07 17:04:38 Re: BUG #15977: Inconsistent behavior in chained transactions
Previous Message Fabien COELHO 2019-09-07 13:23:05 Re: BUG #15977: Inconsistent behavior in chained transactions