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 Postg배트맨 토토SQL |
> 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 |
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 |
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 |