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
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
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
> 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
> 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
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
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
> 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
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
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
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
11 matches
Mail list logo