Re: A assert failure when initdb with track_commit_timestamp=on

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
Cc: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, Andy Fan <zhihuifan1213(at)163(dot)com>, "'Michael Paquier'" <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: A assert failure when initdb with track_commit_timestamp=on
Date: 2025-07-04 15:30:17
Message-ID: 249358.1751643017@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> writes:
> On 2025/07/04 16:29, Hayato Kuroda (Fujitsu) wrote:
>> If more GUCs were found which cannot be set during the bootstrap mode, how about
>> introducing a new flag like GUC_DEFAULT_WHILE_BOOTSTRAPPING for GUC variables?
>> If the flag is set all setting can be ignored when
>> IsBootstrapProcessingMode() = true.

> If there are many GUCs that behave incorrectly during bootstrap,
> a general mechanism like that might be worth considering. But if
> only a few GUCs are affected, as I believe is the case,
> then such a mechanism may be overkill.

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.

The core of the patch could be as little as

diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
index 667df448732..43f289924e6 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()) &&
+ (record->flags & GUC_IGNORE_IN_BOOTSTRAP) &&
+ source != PGC_S_DEFAULT)
+ changeVal = false;
+
/*
* Check if the option can be set at this time. See guc.h for the precise
* rules.

If we went this way, we'd presumably revert 5a6c39b6d in favor
of marking track_commit_timestamp with this flag.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ross Heaney 2025-07-04 15:42:36 Re: Bloom Filter improvements in postgesql
Previous Message Tomas Vondra 2025-07-04 15:23:29 Re: Changing shared_buffers without restart