Re: A assert failure when initdb with track_commit_timestamp=on
Fujii Masao <masao.fujii@oss.nttdata.com>
From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: Andy Fan <zhihuifan1213@163.com>,
"Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
Cc: 'Michael Paquier' <michael@paquier.xyz>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2025-07-03T16:26:19Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Disable commit timestamps during bootstrap
- 8bca4476f9f9 13.22 landed
- b61ddcaf41cf 14.19 landed
- dcbbd43317c0 15.14 landed
- 7e7059abfd22 16.10 landed
- ae20c105f0b2 17.6 landed
- 29a4b63c6bc8 18.0 landed
- 5a6c39b6df33 19 (unreleased) landed
On 2025/07/03 22:31, Andy Fan wrote:
> "Hayato Kuroda (Fujitsu)" <kuroda.hayato@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