Horton

Re: A assert failure when initdb with track_commit_timestamp=on

Fujii Masao <masao.fujii@oss.nttdata.com>

View thread
From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, Andy Fan <zhihuifan1213@163.com>
Cc: 'Michael Paquier' <michael@paquier.xyz>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2025-07-04T08:45:46Z
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 →

  1. Disable commit timestamps during bootstrap


On 2025/07/04 16:29, Hayato Kuroda (Fujitsu) wrote:
> Dear Fujii-san,
> 
>> By the way, although it's a separate issue, I noticed that running
>> initdb -c transaction_timeout=1 causes an assertion failure:
> 
> I feel it may be able to discuss in other places

OK, I've started a new thread for this issue at [1].


> If more GUCs were found which cannot be set during the bootstrap mode, how about
> introducing a new flag like GUC_DEFAULT_WHILE_BOOTSTRAPPING for GUC variables?
> If the flag is set all setting can be ignored when
> IsBootstrapProcessingMode() = true.

If there are many GUCs that behave incorrectly during bootstrap,
a general mechanism like that might be worth considering. But if
only a few GUCs are affected, as I believe is the case,
then such a mechanism may be overkill.

In that case, IMO it should be sufficient to disable the problematic
GUCs individually, for example by calling SetConfigOption(..., PGC_S_OVERRIDE).

Regards,

[1] https://postgr.es/m/a68fae7d-f45a-4c70-8d90-2a2cd3bdcfca@oss.nttdata.com

-- 
Fujii Masao
NTT DATA Japan Corporation