Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uY6bu-0019uH-Hf for pgsql-hackers@arkaria.postgresql.org; Sat, 05 Jul 2025 17:23:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1uY6br-008Ily-Ec for pgsql-hackers@arkaria.postgresql.org; Sat, 05 Jul 2025 17:23:32 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uY6br-008Ilq-4y for pgsql-hackers@lists.postgresql.org; Sat, 05 Jul 2025 17:23:31 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1uY6bp-005vR1-2K for pgsql-hackers@postgresql.org; Sat, 05 Jul 2025 17:23:31 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 565HNDuP009094; Sat, 5 Jul 2025 13:23:13 -0400 From: Tom Lane To: Fujii Masao cc: "Hayato Kuroda (Fujitsu)" , Andy Fan , "'Michael Paquier'" , PostgreSQL Hackers Subject: Re: A assert failure when initdb with track_commit_timestamp=on In-reply-to: <75d59502-b571-4df8-9269-fd07cee52dd4@oss.nttdata.com> References: <87plejmnpy.fsf@163.com> <1f8f703d-72e8-4d05-ab16-ff0403a1d19d@oss.nttdata.com> <87o6u19z9w.fsf@163.com> <3694f39a-7148-4197-91fe-25f3d01222b7@oss.nttdata.com> <249358.1751643017@sss.pgh.pa.us> <262595.1751649473@sss.pgh.pa.us> <75d59502-b571-4df8-9269-fd07cee52dd4@oss.nttdata.com> Comments: In-reply-to Fujii Masao message dated "Sun, 06 Jul 2025 01:57:36 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9092.1751736193.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Sat, 05 Jul 2025 13:23:13 -0400 Message-ID: <9093.1751736193@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Fujii Masao 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 "IgnoreSystemIn= dexes =3D 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=3Doff, > like this: > $ initdb -D data -c ignore_system_indexes=3Doff > ... > FATAL: could not open relation with OID 2703 > PANIC: cannot abort transaction 1, it was already committed > So perhaps "IgnoreSystemIndexes =3D true;" should be placed after GUCs a= re 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