Horton

Thread

Commits

  1. Fix COMMIT/ROLLBACK AND CHAIN in the presence of subtransactions.

  2. Don't use static storage for SaveTransactionCharacteristics().

  3. Transaction chaining

  1. BUG #18118: bug report for COMMIT AND CHAIN feature

    The Post Office <noreply@postgresql.org> — 2023-09-20T09:31:41Z

    The following bug has been logged on the website:

Bug reference:      18118
Logged by:          Liu Xiang
Email address:      evan.lx@alibaba-inc.com
PostgreSQL version: 14.9
Operating system:   centos7
Description:        

COMMIT(280a408b48d5ee42969f981bceb9e9426c3a344c) provides a way to support
chained commits. During recent development, I found that it left a flaw.

The defect can be reproduced as follows:

START TRANSACTION ISOLATION LEVEL SERIALIZABLE; COMMIT;
START TRANSACTION ISOLATION LEVEL REPEATABLE READ\; savepoint s\; COMMIT AND
CHAIN;
SHOW transaction_isolation; -- transaction is active at this point
COMMIT;

will get:
postgres=*# SHOW transaction_isolation; -- transaction is active at this
point
  transaction_isolation
-----------------------
  serializable
(1 row)

The reason for this bug is that in the case of
CommitTransactionCommand->TBLOCK_SUBCOMMIT, if there is a sub-transaction,
only RestoreTransactionCharacteristics will be performed instead of
SaveTransactionCharacteristics; this results in a global variable
save_XactIsoLevel remaining from the previous transaction being restored in
the transaction.

Thank you to the community for your continued help

  2. Re: BUG #18118: bug report for COMMIT AND CHAIN feature

    Laurenz Albe <laurenz.albe@cybertec.at> — 2023-09-21T06:41:20Z

    On Wed, 2023-09-20 at 09:31 +0000, PG Bug reporting form wrote:
> PostgreSQL version: 14.9
> Operating system:   centos7
> Description:        
> 
> COMMIT(280a408b48d5ee42969f981bceb9e9426c3a344c) provides a way to support
> chained commits. During recent development, I found that it left a flaw.
> 
> The defect can be reproduced as follows:
> 
> START TRANSACTION ISOLATION LEVEL SERIALIZABLE; COMMIT;
> START TRANSACTION ISOLATION LEVEL REPEATABLE READ\; savepoint s\; COMMIT AND
> CHAIN;
> SHOW transaction_isolation; -- transaction is active at this point
> COMMIT;
> 
> will get:
> postgres=*# SHOW transaction_isolation; -- transaction is active at this
> point
>   transaction_isolation
> -----------------------
>   serializable
> (1 row)

I tried to reproduce that and failed, both with v14 and v16.

For me, "transaction_isolation" is "repeatable read".

Yours,
Laurenz Albe

  3. 回复：Re: BUG #18118: bug report for COMMIT AND CHAIN feature

    刘相 (佑熙) <evan.lx@alibaba-inc.com> — 2023-09-21T07:12:18Z

    This problem seems to have been solved in v15 and v16. Because of this patch (12d768e70497afc5a57acf73c251316997b5175a), the use of static variables has been cancelled. But this problem can obviously be reproduced on v14(and perhaps v12 v13). Try the following SQL again.

START TRANSACTION ISOLATION LEVEL SERIALIZABLE; COMMIT AND CHAIN; COMMIT ;
START TRANSACTION ISOLATION LEVEL SERIALIZABLE; COMMIT ;
START TRANSACTION ISOLATION LEVEL REPEATABLE READ; savepoint s; COMMIT AND CHAIN;
SHOW transaction_isolation; -- transaction is active at this point
COMMIT;------------------------------------------------------------------
发件人：Laurenz Albe<laurenz.albe@cybertec.at>
日　期：2023年09月21日 14:41:20
收件人：刘相(佑熙)<evan.lx@alibaba-inc.com>; <pgsql-bugs@lists.postgresql.org>
主　题：Re: BUG #18118: bug report for COMMIT AND CHAIN feature

On Wed, 2023-09-20 at 09:31 +0000, PG Bug reporting form wrote:
> PostgreSQL version: 14.9
> Operating system:   centos7
> Description:        
> 
> COMMIT(280a408b48d5ee42969f981bceb9e9426c3a344c) provides a way to support
> chained commits. During recent development, I found that it left a flaw.
> 
> The defect can be reproduced as follows:
> 
> START TRANSACTION ISOLATION LEVEL SERIALIZABLE; COMMIT;
> START TRANSACTION ISOLATION LEVEL REPEATABLE READ\; savepoint s\; COMMIT AND
> CHAIN;
> SHOW transaction_isolation; -- transaction is active at this point
> COMMIT;
> 
> will get:
> postgres=*# SHOW transaction_isolation; -- transaction is active at this
> point
>   transaction_isolation
> -----------------------
>   serializable
> (1 row)

I tried to reproduce that and failed, both with v14 and v16.

For me, "transaction_isolation" is "repeatable read".

Yours,
Laurenz Albe

  4. Re: 回复：Re: BUG #18118: bug report for COMMIT AND CHAIN feature

    Tom Lane <tgl@sss.pgh.pa.us> — 2023-09-21T16:16:56Z

    "=?UTF-8?B?5YiY55u4KOS9keeGmSk=?=" <evan.lx@alibaba-inc.com> writes:
> This problem seems to have been solved in v15 and v16. Because of this patch (12d768e70497afc5a57acf73c251316997b5175a), the use of static variables has been cancelled. But this problem can obviously be reproduced on v14(and perhaps v12 v13). Try the following SQL again.

Oooh ... I see the problem.  It's not really about the use of static
variables.  In the older branches, CommitTransactionCommand does

	if (s->chain)
		SaveTransactionCharacteristics();

....

				if (s->chain)
					RestoreTransactionCharacteristics();

but if we're closing out any subtransactions then *those two checks
are inspecting different "s" structs*, and the "chain" flag has
only been set in the bottom of the state stack.

12d768e70 fixed the problem rather accidentally, because I removed the
initial "if (s->chain)" test to avoid a compiler warning.  I think we
can just do the same in the back branches, without having to address
the question of whether it'd be OK to break API for
SaveTransactionCharacteristics and RestoreTransactionCharacteristics.

			regards, tom lane