From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
cc: Fujii Masao <masao.fujii@oss.nttdata.com>,
        "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>,
        Andy Fan <zhihuifan1213@163.com>,
        PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: A assert failure when initdb with track_commit_timestamp=on
In-reply-to: <aGh9_JYuUr35Qk-g@paquier.xyz>
References: <87plejmnpy.fsf@163.com>
 <1f8f703d-72e8-4d05-ab16-ff0403a1d19d@oss.nttdata.com>
 <aGXZL0oraweaENrF@paquier.xyz>
 <OSCPR01MB14966207D000875CA4F4C9FEAF543A@OSCPR01MB14966.jpnprd01.prod.outlook.com>
 <87o6u19z9w.fsf@163.com>
 <3694f39a-7148-4197-91fe-25f3d01222b7@oss.nttdata.com>
 <OSCPR01MB1496673E2FC58836331748DB6F542A@OSCPR01MB14966.jpnprd01.prod.outlook.com>
 <efd05511-0b1f-4800-9eca-aadbf9bf5375@oss.nttdata.com>
 <249358.1751643017@sss.pgh.pa.us> <aGh9_JYuUr35Qk-g@paquier.xyz>
Comments: In-reply-to Michael Paquier <michael@paquier.xyz>
	message dated "Sat, 05 Jul 2025 10:21:00 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <378328.1751682278.1@sss.pgh.pa.us>
Date: Fri, 04 Jul 2025 22:24:38 -0400
Message-ID: <378329.1751682278@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/378329.1751682278%40sss.pgh.pa.us>
Precedence: bulk

Michael Paquier <michael@paquier.xyz> writes:
> This is assuming that the default value assigned to a GUC will always
> take the right decision in the bootstrap case, which is perhaps OK
> anyway in most cases, or we would know about that during initdb.

Yeah, I've been wondering about whether the code ought to accept
source == PGC_S_DYNAMIC_DEFAULT.  It doesn't matter until/unless
we need to set this flag on a GUC that has code to compute a
dynamic default, so any decision we made right now would be made
in a vacuum ... but perhaps the right guess is to allow it.

>> If we went this way, we'd presumably revert 5a6c39b6d in favor
>> of marking track_commit_timestamp with this flag.

> Makes sense, on HEAD.

Well, you back-patched 5a6c39b6d, so it's not clear to me why
we wouldn't want to back-patch something to fix any other GUC
suffering from a comparable problem.  I don't see that adding
another possible GUC flag is an ABI break, especially when it's
a flag that no extension could have a need to set.

			regards, tom lane