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
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 |