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 1neMfU-0005oJ-KC for pgsql-hackers@arkaria.postgresql.org; Tue, 12 Apr 2022 19:59:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1neMfT-0003hU-Dn for pgsql-hackers@arkaria.postgresql.org; Tue, 12 Apr 2022 19:59:15 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1neMfT-0003hJ-2q for pgsql-hackers@lists.postgresql.org; Tue, 12 Apr 2022 19:59:15 +0000 Received: from mail-pj1-x102f.google.com ([2607:f8b0:4864:20::102f]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1neMfQ-0000Fi-H4 for pgsql-hackers@lists.postgresql.org; Tue, 12 Apr 2022 19:59:14 +0000 Received: by mail-pj1-x102f.google.com with SMTP id mm4-20020a17090b358400b001cb93d8b137so4086994pjb.2 for ; Tue, 12 Apr 2022 12:59:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=k28mRbPhIitAWFSZxC5yCfumFPuxHhk3lFjOhwi7lYk=; b=CbJYeMdGiNPB/Jj//6SjIpl/nYcXING4F9rQFpeUU5LeJ8KTXJWZerEuUtVobU3S7+ qYHSP8rQHCMvO2PuFseh8DOg1fBYzHaiaPCIhYhe3wN8VWTSnxk7vAHPDE5/Qbk7YQ7d q8eprh+6KHT4nMIjbRxfiwAJUr0mA0bi33bUlEIKzoYwCxVi1C9r6SvcM944SF2yay0q LANaOidRDXvcKf4/qYsuK7itim1l6ydNynfQKjbrVzXZUNh9lEciLMK39DzfJK7jnrYY KipQsRyfAGVVuNe50nbRkoCrzf9Z4ed16IgNknjzfBJW1XHn8JU6vmsRredRfWqs8Qys kAew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=k28mRbPhIitAWFSZxC5yCfumFPuxHhk3lFjOhwi7lYk=; b=0HJLGOJd+uC2F1qepPy7aYTV0i3zQ/38pazGfQu5HmgbRgY/s8yOGDkmksEzJTET+Q MRN5ghgTG0YiQX/cCih1j1rcWB0A/QqHCM6NnQ2EoYEkM6DPxChWDl4IFDwX8+I/jTJQ C8XlYtOFZ8TzG6iOovien7u9YhRkTz4v3yMfaSu44iWCp2VGZXGhM6Fr/4J+T0OxJ3MP Q1R0KR3cSU9WA45MzTcPS0ErC2IcIDulWB75vN+nEAqpdncVyI9KqKBsHhUJO/vOVGj7 Hqr4/VFs8OruMOai4DUiMvLnVDkJsC9ZUB8hZMF+qsIs5JnywKMpFKtGQqrq8YLXYV8w EXOw== X-Gm-Message-State: AOAM531KBlfY0nZlUkSFSt0YifJllXDHslXFiOSlPMzaxEKZ4q9mFKMs UerCCRx2GSjUTythjQmWUUM= X-Google-Smtp-Source: ABdhPJyxv7TQEpBofMISjEail32eHnrjWBKI7M2EoT/QEZYHFk4DOdc79mg9up1BWQGUekq9mUhcPA== X-Received: by 2002:a17:903:41ca:b0:158:7f07:e7bc with SMTP id u10-20020a17090341ca00b001587f07e7bcmr7363779ple.32.1649793550653; Tue, 12 Apr 2022 12:59:10 -0700 (PDT) Received: from nathanxps13 ([50.54.155.70]) by smtp.gmail.com with ESMTPSA id g1-20020a633741000000b0039958c06c53sm3473587pgn.61.2022.04.12.12.59.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Apr 2022 12:59:10 -0700 (PDT) Date: Tue, 12 Apr 2022 12:59:08 -0700 From: Nathan Bossart To: Robert Haas Cc: Tom Lane , Andres Freund , Julien Rouhaud , Michael Paquier , "Bossart, Nathan" , Fujii Masao , "wangsh.fnst@fujitsu.com" , Bharath Rupireddy , Greg Sabino Mullane , "pgsql-hackers@lists.postgresql.org" Subject: Re: make MaxBackends available in _PG_init Message-ID: <20220412195908.GA2064996@nathanxps13> References: <20220411164408.GA1915258@nathanxps13> <20220411204442.GA2004824@nathanxps13> <20220411211435.GA2057981@nathanxps13> <20220412174427.sngj2uexzsttazs2@alap3.anarazel.de> <20220412180306.GA2063516@nathanxps13> <908945.1649791317@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Apr 12, 2022 at 03:30:23PM -0400, Robert Haas wrote: > On Tue, Apr 12, 2022 at 3:22 PM Tom Lane wrote: >> Yeah. It's a very long way from "changing shared memory sizes here >> doesn't work" to "no extension is allowed to change any GUC at load >> time". A counterexample is that it's not clear why an extension >> shouldn't be allowed to define a GUC using DefineCustomXXXVariable >> and then immediately set it to some other value. I think trying to >> forbid that across-the-board is going to mostly result in breaking >> a lot of cases that are perfectly safe. > > Hmm, that's an interesting case which I hadn't considered. It seems > like sort of a lame thing to do, because why wouldn't you just create > the GUC with the right initial value instead of modifying it after the > fact? But maybe there's some use case in which it makes sense to do it > that way. A read-only GUC that advertises some calculated value, > perhaps? I think it'd be reasonable to allow changing custom GUCs in _PG_init(). Those aren't going to impact things like MaxBackends. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com