From: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Assertion failure during initdb with transaction_timeout set |
Date: | 2025-07-04 08:37:01 |
Message-ID: | a68fae7d-f45a-4c70-8d90-2a2cd3bdcfca@oss.nttdata.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
While discussing the assertion failure with track_commit_timestamp=on during initdb [1],
I found a similar issue with another GUC: transaction_timeout.
Running initdb -c transaction_timeout=1 triggers the following 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 start the transaction timeout
before InitializeTimeouts() has been called, i.e., the timeout subsystem
hasn't been initialized yet.
To address this, I'm thinking forcibly setting transaction_timeout to 0
during bootstrap or in initdb.
Any thoughts?
Regards,
[1] https://postgr.es/m/87plejmnpy.fsf@163.com
--
Fujii Masao
NTT DATA Japan Corporation
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2025-07-04 08:45:46 | Re: A assert failure when initdb with track_commit_timestamp=on |
Previous Message | Andrey Borodin | 2025-07-04 08:31:53 | Re: Add 64-bit XIDs into PostgreSQL 15 |