Re: A assert failure when initdb with track_commit_timestamp=on

From: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
To: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, Andy Fan <zhihuifan1213(at)163(dot)com>
Cc: 'Michael Paquier' <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: A assert failure when initdb with track_commit_timestamp=on
Date: 2025-07-04 08:45:46
Message-ID: efd05511-0b1f-4800-9eca-aadbf9bf5375@oss.nttdata.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Xuneng Zhou 2025-07-04 08:57:22 Re: Add progressive backoff to XactLockTableWait functions
Previous Message Fujii Masao 2025-07-04 08:37:01 Assertion failure during initdb with transaction_timeout set