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
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 |