pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Andy Fan <zhihuifan1213@163.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>
Cc: 'Michael Paquier' <michael@paquier.xyz>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: A assert failure when initdb with track_commit_timestamp=on
Date: Tue, 08 Jul 2025 09:01:52 +0800
Message-ID: <87tt3na41r.fsf@163.com> (raw)
In-Reply-To: <61810.1751738407@sss.pgh.pa.us>
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>



> 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






view thread (28+ messages)  latest in thread

Message-ID: <87tt3na41r.fsf@163.com>
Permalink:  ../87tt3na41r.fsf@163.com/
Also on:    postgresql.org/message-id/87tt3na41r.fsf@163.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: zhihuifan1213@163.com, tgl@sss.pgh.pa.us, masao.fujii@oss.nttdata.com, kuroda.hayato@fujitsu.com, michael@paquier.xyz
  Subject: Re: A assert failure when initdb with track_commit_timestamp=on
  In-Reply-To: <87tt3na41r.fsf@163.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox