From: Tom Lane <tgl@sss.pgh.pa.us>
To: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>
Cc: Andy Fan <zhihuifan1213@163.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: Sat, 05 Jul 2025 13:23:13 -0400
Message-ID: <9093.1751736193@sss.pgh.pa.us> (raw)
In-Reply-To: <75d59502-b571-4df8-9269-fd07cee52dd4@oss.nttdata.com>
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>
Fujii Masao <masao.fujii@oss.nttdata.com> writes:
> On 2025/07/05 2:17, Tom Lane wrote:
>> Oh, good point. But there doesn't seem to be any ill effect from
>> making BootstrapModeMain set BootstrapProcessing a bit earlier.
> Maybe. But I noticed that your patch also moves the line "IgnoreSystemIndexes = true;"
> earlier. Why did you make this change?
It just seemed to go with the bootstrap-mode setting. But your
example shows differently:
> This could cause initdb to fail with a PANIC error when run with ignore_system_indexes=off,
> like this:
> $ initdb -D data -c ignore_system_indexes=off
> ...
> FATAL: could not open relation with OID 2703
> PANIC: cannot abort transaction 1, it was already committed
> So perhaps "IgnoreSystemIndexes = true;" should be placed after GUCs are processed?
Yeah, we should do it like that (and probably also have a comment...)
> 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.
BTW, I now realize that this is only an issue starting from v16.
Before that initdb didn't have a -c switch, so there was not a
way for people to shove random settings into it.
regards, tom lane
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: tgl@sss.pgh.pa.us, masao.fujii@oss.nttdata.com, kuroda.hayato@fujitsu.com, zhihuifan1213@163.com, michael@paquier.xyz
Subject: Re: A assert failure when initdb with track_commit_timestamp=on
In-Reply-To: <9093.1751736193@sss.pgh.pa.us>
* 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