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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: 刘相(佑熙) <evan(dot)lx(at)alibaba-inc(dot)com>
Cc: "Laurenz Albe" <laurenz(dot)albe(at)cybertec(dot)at>, "pgsql-bugs" <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: 回复:Re: BUG #18118: bug report for COMMIT AND CHAIN feature
Date: 2023-09-21 16:16:56
Message-ID: 710008.1695313016@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"=?UTF-8?B?5YiY55u4KOS9keeGmSk=?=" <evan(dot)lx(at)alibaba-inc(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Aleš Zelený 2023-09-21 17:56:14 Invalid dump file after drop of role that previously created extension containing a table.
Previous Message Tom Lane 2023-09-21 15:01:30 Re: BUG #18126: Ordered set aggregate: result does not depend on sort order