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 1uXc3P-00C56A-Qn for pgsql-hackers@arkaria.postgresql.org; Fri, 04 Jul 2025 08:45:55 +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 1uXc3M-00HPqc-NG for pgsql-hackers@arkaria.postgresql.org; Fri, 04 Jul 2025 08:45:53 +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 1uXc3M-00HPqO-DQ for pgsql-hackers@lists.postgresql.org; Fri, 04 Jul 2025 08:45:53 +0000 Received: from oss.nttdata.com ([49.212.34.109]) by magus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1uXc3K-005fAN-28 for pgsql-hackers@postgresql.org; Fri, 04 Jul 2025 08:45:52 +0000 Received: from [192.168.11.9] (p1696134-ipoe.ipoe.ocn.ne.jp [118.0.93.133]) by oss.nttdata.com (Postfix) with ESMTPSA id C58A461C08; Fri, 4 Jul 2025 17:45:46 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at oss.nttdata.com Message-ID: Date: Fri, 4 Jul 2025 17:45:46 +0900 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: A assert failure when initdb with track_commit_timestamp=on Content-Language: en-US To: "Hayato Kuroda (Fujitsu)" , Andy Fan Cc: 'Michael Paquier' , PostgreSQL Hackers 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> From: Fujii Masao In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2025/07/04 16:29, Hayato Kuroda (Fujitsu) wrote: > Dear Fujii-san, > >> By the way, although it's a separate issue, I noticed that running >> initdb -c transaction_timeout=1 causes an assertion failure: > > I feel it may be able to discuss in other places OK, I've started a new thread for this issue at [1]. > 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. In that case, IMO it should be sufficient to disable the problematic GUCs individually, for example by calling SetConfigOption(..., PGC_S_OVERRIDE). Regards, [1] https://postgr.es/m/a68fae7d-f45a-4c70-8d90-2a2cd3bdcfca@oss.nttdata.com -- Fujii Masao NTT DATA Japan Corporation