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 1uXiN2-00DW0k-8V for pgsql-hackers@arkaria.postgresql.org; Fri, 04 Jul 2025 15:30:36 +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 1uXiMz-001ZG5-7E for pgsql-hackers@arkaria.postgresql.org; Fri, 04 Jul 2025 15:30:33 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uXiMy-001ZFq-Tg for pgsql-hackers@lists.postgresql.org; Fri, 04 Jul 2025 15:30:33 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1uXiMx-005Z1r-2h for pgsql-hackers@postgresql.org; Fri, 04 Jul 2025 15:30:32 +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 564FUHJT249359; Fri, 4 Jul 2025 11:30:17 -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: 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> Comments: In-reply-to Fujii Masao message dated "Fri, 04 Jul 2025 17:45:46 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <249357.1751643017.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Fri, 04 Jul 2025 11:30:17 -0400 Message-ID: <249358.1751643017@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/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 var= iables? >> If the flag is set all setting can be ignored when >> IsBootstrapProcessingMode() =3D 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_han= dle *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 !=3D PGC_S_DEFAULT) + changeVal =3D false; + /* * Check if the option can be set at this time. See guc.h for the precis= e * rules. If we went this way, we'd presumably revert 5a6c39b6d in favor of marking track_commit_timestamp with this flag. regards, tom lane