On 2025/07/03 22:31, Andy Fan wrote:
"Hayato Kuroda (Fujitsu)" <kuroda.hay...@fujitsu.com> writes:
Dear Michael, Fujii-san,
Ah, indeed, so it was reported a couple of months ago. I am not sure
that the argument about all the other GUCs potentially impacted holds
much value; we are talking about a specific code path.
Yeah, I did report but sadly it was missed by others :-(. To clarify,
The current patch looks good to me.
Then I'd thank Michael to watch the maillist closely this time.
I checked the fix suggested by Hayato, I think his patch is better than
me because his patch checks at the startup time while my patch checks at
each time of RecordTransactionCommit. So v3 takes his patch. v3 also
added the testcase suggested by Michael for test coverage, it clearly
proves the bug is fixed now.
The patch looks good to me.
By the way, although it's a separate issue, I noticed that running
initdb -c transaction_timeout=1 causes an assertion failure:
running bootstrap script ... TRAP: failed Assert("all_timeouts_initialized"), File:
"timeout.c", Line: 164, PID: 22057
0 postgres 0x00000001105d9d02 ExceptionalCondition
+ 178
1 postgres 0x0000000110612af7 enable_timeout + 55
2 postgres 0x0000000110612aa9 enable_timeout_after
+ 73
3 postgres 0x000000010fead8e0 StartTransaction +
816
4 postgres 0x000000010fead4a1
StartTransactionCommand + 65
5 postgres 0x000000010fef01de BootstrapModeMain +
1518
6 postgres 0x0000000110167ef4 main + 676
7 dyld 0x00007ff805092530 start + 3056
child process was terminated by signal 6: Abort trap: 6
This happens because enable_timeout() tries to activate the transaction
timeout before InitializeTimeouts() has been called — in other words,
the timeout system hasn't been initialized yet. To fix this, we might
need to forcibly set transaction_timeout to 0 during bootstrap.
Regards,
--
Fujii Masao
NTT DATA Japan Corporation
