Re: BUG #15977: Inconsistent behavior in chained transactions

2019-09-09 Thread fn ln
It looks good now. Thank you again. 2019年9月9日(月) 17:43 Peter Eisentraut : > On 2019-09-09 05:58, fn ln wrote: > > Confirmed. Thank you all for your help. > > > > The only concern is that this test: > > > >SET TRANSACTION READ WRITE\; COMMIT

Re: BUG #15977: Inconsistent behavior in chained transactions

2019-09-08 Thread fn ln
because default_transaction_read_only is off at this point. 2019年9月9日(月) 5:27 Peter Eisentraut : > On 2019-09-07 18:32, fn ln wrote: > >> Missed them somehow. But I don't think they're quite sufficient. I think > >> at least we also need tests that test things like m

Re: BUG #15977: Inconsistent behavior in chained transactions

2019-09-07 Thread fn ln
No, but instead always do an implicit COMMIT after each statement, like SELECT 1; SELECT 2; (not \;) in psql. The PostgreSQL document even states that 'Issuing COMMIT when not inside a transaction does no harm, but it will provoke a warning message.' for a long time, but in fact it have side-effect

Re: BUG #15977: Inconsistent behavior in chained transactions

2019-09-07 Thread fn ln
> 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

Re: BUG #15977: Inconsistent behavior in chained transactions

2019-09-07 Thread fn ln
> Looking at the latest patch, the comment blocks on top of TBLOCK_STARTED > and TBLOCK_IMPLICIT_INPROGRESS in EndTransactionBlock() need an update > to mention the difference of behavior with chained transactions. And > the same comment rework should be done in UserAbortTransactionBlock() > for T

Re: BUG #15977: Inconsistent behavior in chained transactions

2019-09-04 Thread fn ln
I made another patch for suggested behavior (COMMIT/ROLLBACK AND CHAIN now gives us an error when used in an implicit block). 2019年9月4日(水) 16:53 Andres Freund : > Hi, > > On 2019-09-03 11:54:57 +0200, Peter Eisentraut wrote: > > On 2019-08-29 16:58, Fabien COELHO wrote: > > > > > >> Thanks, I got

Re: BUG #15977: Inconsistent behavior in chained transactions

2019-09-03 Thread fn ln
We have three options: 1. Prohibit AND CHAIN outside a transaction block, but do nothing in plain COMMIT/ROLLBACK or AND NO CHAIN. 2. Deal "there is no transaction in progress" (and "there is already a transaction in progress" if needed) as an error. 3. Leave as it is. Option 1 makes overal

Re: BUG #15977: Inconsistent behavior in chained transactions

2019-08-29 Thread fn ln
> The usual approach is to send self-contained and numbered patches, > eg "chain-fix-1.patch", "chain-fix-2.patch", and so on, unless there are > complex patches designed to be committed in stages. Thanks, I got it. I have never made a patch before so I'll keep it in my mind. Self-contained patch

Re: BUG #15977: Inconsistent behavior in chained transactions

2019-08-29 Thread fn ln
Added two kinds of test for the implicit transaction: in single query and in implicit block. The patch file is now created with Unix-style line ending (LF). 2019年8月29日(木) 15:30 Fabien COELHO : > > Hello, > > > COMMIT AND CHAIN in implicit block leaves blockState as TBLOCK_STARTED, > > which doesn

Re: BUG #15977: Inconsistent behavior in chained transactions

2019-08-29 Thread fn ln
transaction_read_only must be 'on' because AND CHAIN test sets the default_transaction_read_only to 'on'. Failure of this test means that the transaction was chained from an implicit transaction, which is not our desired behavior. Perhaps you are using a wrong binary? 2019年8月29日(木) 21:10 Fabien C

Re: BUG #15977: Inconsistent behavior in chained transactions

2019-08-29 Thread fn ln
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:1