From: Andy Fan <zhihuifan1213@163.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Fujii Masao <masao.fujii@oss.nttdata.com>,  "Hayato Kuroda (Fujitsu)"
 <kuroda.hayato@fujitsu.com>,  "'Michael Paquier'" <michael@paquier.xyz>,
  PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: A assert failure when initdb with track_commit_timestamp=on
In-Reply-To: <61810.1751738407@sss.pgh.pa.us> (Tom Lane's message of "Sat, 05
	Jul 2025 14:00:07 -0400")
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>
	<ac5d452d-7e9d-4643-b9e7-cb3423b04365@oss.nttdata.com>
	<262595.1751649473@sss.pgh.pa.us>
	<75d59502-b571-4df8-9269-fd07cee52dd4@oss.nttdata.com>
	<9093.1751736193@sss.pgh.pa.us> <61810.1751738407@sss.pgh.pa.us>
Date: Tue, 08 Jul 2025 09:01:52 +0800
Message-ID: <87tt3na41r.fsf@163.com>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://www.postgresql.org/message-id/87tt3na41r.fsf%40163.com>
Precedence: bulk


> I wrote:
>> Fujii Masao <masao.fujii@oss.nttdata.com> writes:
>>> Or GUC ignore_system_indexes also should be treated in the same way
>>> as transaction_timeout?
>
>> Yes, I'd say we ought to mark that GUC as don't-accept-in-bootstrap
>> too.  I've not done any research about what other GUCs can break
>> initdb, but now I'm starting to suspect there are several.
>
> Here's a fleshed-out implementation of Hayato-san's idea.  I've
> not done anything about reverting 5a6c39b6d, nor have I done any
> checks to see if there are other GUCs we ought to mark similarly.
> (But at this point I'd be prepared to bet that there are.)

I pay my attention to two cases, both of them are good.

(1). Revert the old commit 5a6c39b6d first, and apply your patch. verify
initdb with -c transaction_timeout and track_commit_timestamp, both of
them works well.  transaction_timeout with a smaller value raise
transaction_timeout error. and a biggger value works well.  

(2). after (1), check values of transaction_timeout and
track_commit_timestamp in postgres.conf, both of them are good (with the
default value as the user provided in the initdb commandline). 

So the patch looks good to me, thanks for paying attention to this
issue! 

-- 
Best Regards
Andy Fan