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: Fri, 04 Jul 2025 13:17:53 -0400
Message-ID: <262595.1751649473@sss.pgh.pa.us> (raw)
In-Reply-To: <ac5d452d-7e9d-4643-b9e7-cb3423b04365@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>
Fujii Masao <masao.fujii@oss.nttdata.com> writes:
> On 2025/07/05 0:30, Tom Lane wrote:
>> As I remarked in the other thread, I don't like inventing a different
>> solution for each GUC. So if there are even two that need something
>> done, I think Hayato-san's idea has merit.
> This code seems to assume that the processing mode is switched to bootstrap before
> GUC parameters are processed. But is that actually the case?
Oh, good point. But there doesn't seem to be any ill effect from
making BootstrapModeMain set BootstrapProcessing a bit earlier.
Attached is a proof-of-concept that I've actually tested.
However, what I find with this POC is that
initdb -c transaction_timeout=10s
goes through fine, but (at least on my machine)
initdb -c transaction_timeout=1
yields
...
running bootstrap script ... ok
performing post-bootstrap initialization ... 2025-07-04 13:08:04.225 EDT [261836] FATAL: terminating connection due to transaction timeout
child process exited with exit code 1
because 1ms is not enough time to complete the post-bootstrap run.
I would argue that that's pilot error and we did exactly what the
user demanded, but is there anyone who wants to say that we should
suppress such GUCs during post-bootstrap too?
regards, tom lane
Attachments:poc-survive-transaction_timeout-in-initdb.patch (text/x-diff, 1.3K) downloaddiff --git a/src/backend/bootstrap/bootstrap.c b/src/backend/bootstrap/bootstrap.cindex fc8638c1b61..facad43c74c 100644--- a/src/backend/bootstrap/bootstrap.c+++ b/src/backend/bootstrap/bootstrap.c@@ -220,6 +220,9 @@ BootstrapModeMain(int argc, char *argv[], bool check_only)
argv++;
argc--;
+ SetProcessingMode(BootstrapProcessing);+ IgnoreSystemIndexes = true;+
while ((flag = getopt(argc, argv, "B:c:d:D:Fkr:X:-:")) != -1)
{
switch (flag)
@@ -321,9 +324,6 @@ BootstrapModeMain(int argc, char *argv[], bool check_only)
CreateDataDirLockFile(false);
- SetProcessingMode(BootstrapProcessing);- IgnoreSystemIndexes = true;-
InitializeMaxBackends();
/*
diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.cindex 667df448732..9555b363c34 100644--- a/src/backend/utils/misc/guc.c+++ b/src/backend/utils/misc/guc.c@@ -3464,6 +3464,15 @@ set_config_with_handle(const char *name, config_handle *handle,
return 0;
}
+ /*+ * Certain GUCs aren't safe to enable during bootstrap mode. Silently+ * ignore attempts to set them to non-default values.+ */+ if (unlikely(IsBootstrapProcessingMode()) &&+ strcmp(record->name, "transaction_timeout") == 0 &&+ source != PGC_S_DEFAULT)+ changeVal = false;+
/*
* Check if the option can be set at this time. See guc.h for the precise
* rules.
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: <262595.1751649473@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