Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pnEoo-0004rT-BW for pgsql-hackers@arkaria.postgresql.org; Fri, 14 Apr 2023 08:30:06 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pnEom-0007zT-WC for pgsql-hackers@arkaria.postgresql.org; Fri, 14 Apr 2023 08:30:05 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pnEol-0007zK-U6 for pgsql-hackers@lists.postgresql.org; Fri, 14 Apr 2023 08:30:04 +0000 Received: from new4-smtp.messagingengine.com ([66.111.4.230]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pnEoe-0006eh-Sv for pgsql-hackers@lists.postgresql.org; Fri, 14 Apr 2023 08:30:02 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailnew.nyi.internal (Postfix) with ESMTP id B0AFA58230A; Fri, 14 Apr 2023 04:29:55 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Fri, 14 Apr 2023 04:29:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1681460995; x= 1681468195; bh=LJSBeDphZGnGe/lzSsCyl+/HhOmDtFZUKDoziSSd9HQ=; b=Q L1vCc+h1fL26DKNuRejHuC6WfaitoKCvmFOb1+bwYcJ7m3knWzar50bUIJseAAN8 cZiCONcVnRN9SptaKZuQZ3x862B6THF1ufkuNcZdx0Wl3bqt1qCMU8OQWN62lPgJ wJLMXXefMlotZig4HTaar6CsTQlko/gPAvKFRNz1d6dN7Fee5ukQRwz91fDI2j5G a4nvimbMgT0ecxJIF20EJ5mln1Isjz7UWith8Pk1gGN9iafOYxCKQ0wrR0EPxXbL WcaxWCa+HJn5fAizYpSUpaKtqllcfJGb9I1F8S9NUml5xwcRD2HTb46RY0RxbSLB n0hUTAs2gK5lE52afW3gg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdeltddgtdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefkffggfgfuhffvfhgjtgfgsehtke ertddtfeejnecuhfhrohhmpefrvghtvghrucfgihhsvghnthhrrghuthcuoehpvghtvghr rdgvihhsvghnthhrrghuthesvghnthgvrhhprhhishgvuggsrdgtohhmqeenucggtffrrg htthgvrhhnpeefgefgteefudehheduffevlefhkeeulefhfffgvdelgfffueduledtgfek iefhjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hpvghtvghrrdgvihhsvghnthhrrghuthesvghnthgvrhhprhhishgvuggsrdgtohhm X-ME-Proxy: Feedback-ID: i131946ab:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 14 Apr 2023 04:29:54 -0400 (EDT) Message-ID: <0307b599-9528-643d-934c-a7e76d376e94@enterprisedb.com> Date: Fri, 14 Apr 2023 10:29:53 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: Re: Set arbitrary GUC options during initdb Content-Language: en-US From: Peter Eisentraut To: Tom Lane , pgsql-hackers@lists.postgresql.org References: <2844176.1674681919@sss.pgh.pa.us> <8a8fda29-5a68-ba68-a2ff-8d17602b3762@enterprisedb.com> In-Reply-To: <8a8fda29-5a68-ba68-a2ff-8d17602b3762@enterprisedb.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 27.01.23 15:48, Peter Eisentraut wrote: > Btw., something that I have had in my notes for a while, but with this > it would now be officially exposed:  Not all options can be safely set > during bootstrap.  For example, > >     initdb -D data -c track_commit_timestamp=on > > will fail an assertion.  This might be an exception, or there might be > others. I ran a test across all changeable boolean parameters with initdb setting it to the opposite of their default. The only one besides track_commit_timestamp that caused initdb to not complete was default_transaction_read_only, which is to be expected. We should fix track_commit_timestamp, but it doesn't look like there is wider impact. (Obviously, this tested only boolean settings. If someone wants to fuzz-test the others ...)