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 1nDfQz-0000Tq-Ix for pgsql-hackers@arkaria.postgresql.org; Sat, 29 Jan 2022 04:33:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nDfQx-0006RP-EY for pgsql-hackers@arkaria.postgresql.org; Sat, 29 Jan 2022 04:33:55 +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 1nDfQx-0006RE-3q for pgsql-hackers@lists.postgresql.org; Sat, 29 Jan 2022 04:33:55 +0000 Received: from mail-pg1-x535.google.com ([2607:f8b0:4864:20::535]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nDfQs-0002HY-UI for pgsql-hackers@lists.postgresql.org; Sat, 29 Jan 2022 04:33:54 +0000 Received: by mail-pg1-x535.google.com with SMTP id h23so7009480pgk.11 for ; Fri, 28 Jan 2022 20:33:50 -0800 (PST) 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=Ly431eVsy1gCD3ztXuE6MSISeM27PWewnPXZ1Rf4uBs=; b=eJsyNqBeFoYM+v9gUsWlz42ZXDE9vbS3lrKUSc9B0007y1TE6S4pchEBMZoyOjGpsC jXTewgbeBQ6D8NrSotDNCloBSYdn4uXglASxSSusiBntMHDZA1pGrN2WNufVZeZKBexN LNomqW9pes1LhbLccplh3IR8PuQiI4y/5DhGCU7d8/o+Ezd2lXSgFZ2mwOwuyhb19PbA TDNBrC4M16Qu9l6ZaaDoLqmQrxdyZVVLpUnivn1UNJYoeWfaOoQBEIlwYuMadJx3YXiW ihNOw1vpNwT4wU7Fa4i0ob+9CG2uhtkgkAyxnSM7WPWNZDfqq7g0uLzgZ1E0YInAMvOm umbw== 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=Ly431eVsy1gCD3ztXuE6MSISeM27PWewnPXZ1Rf4uBs=; b=wQI8+rXT4SA92rZutXjIDkdvxldtL4rKt+ciLWJVCCYR+O29wKhL7kvbO0MlwxtIAl 2+zYTPiytmsA1PVIycbY/2+/w0DP7pt/LvtGhjCCFl4lN9koeYqUvVbf81B9lE3W9hmv RNFcvd6vGbZ7e7GVw/rzpeOKLhsEvWQtg1dC+UED5BrSPCUIvtVPMFvCrrZ4xj+FLwXd 2U4qMzZkE0Vm/KBhRdXT4ky4WMZKsOmqKOxmZb1qppU0AXQELIScUpBgyqzuwDN5s4Md I0JCgyS1DINbp1MfZPzMyiCsdb0zh3fXUNjIah1fLsJiMFta6WGhnmjBDsgk4Ut4LYep GP3g== X-Gm-Message-State: AOAM531rHiRKL1ov9oWf2ekcBTIrLJUODCTqjdUIHfDF36zYL9UAo2op R0dfsSdOQv6YVNJ0EJBOSD8= X-Google-Smtp-Source: ABdhPJwo9XUhGYtACqgDDuhOJUwOb5vGuADjgBC4Pui8S2mUxwd56IV2AEkcxFM2P9TnOqfm5byUrg== X-Received: by 2002:a63:7981:: with SMTP id u123mr9070795pgc.506.1643430828592; Fri, 28 Jan 2022 20:33:48 -0800 (PST) Received: from nathanxps13 ([50.54.155.70]) by smtp.gmail.com with ESMTPSA id md18sm3772880pjb.9.2022.01.28.20.33.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 28 Jan 2022 20:33:48 -0800 (PST) Date: Fri, 28 Jan 2022 20:33:42 -0800 From: Nathan Bossart To: Michael Paquier Cc: "Bossart, Nathan" , Robert Haas , Fujii Masao , "wangsh.fnst@fujitsu.com" , Andres Freund , Bharath Rupireddy , Greg Sabino Mullane , Tom Lane , "pgsql-hackers@lists.postgresql.org" Subject: Re: make MaxBackends available in _PG_init Message-ID: <20220129043342.GA89174@nathanxps13> References: <01c32f6c-8101-1ce4-8295-534cf067df94@oss.nttdata.com> <7239E4F9-A46D-4A61-9200-8B1366D03ADB@amazon.com> <1E960D8B-24D7-43E0-9744-C5F8C52DDEB4@amazon.com> <20220127181815.GA551692@nathanxps13> 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 Sat, Jan 29, 2022 at 11:19:12AM +0900, Michael Paquier wrote: > On Thu, Jan 27, 2022 at 10:18:15AM -0800, Nathan Bossart wrote: >> Alright. I think the comment adjustments still apply, so I split those out >> to a new patch. > > Looks fine after a second look, so applied. Thanks! > As of the issues of this thread, we really have two things to think > about: > 1) How do we want to control the access of some parameters in a > context or another? One idea would be more control through GUCs, say > with a set of context-related flags that prevent the read of some > variables until they are set. We could encourage the use of > GetConfigOption() for that. For MaxBackends, we could add a read-only > GUC for this purpose. That's what Andres hinted at upthread, I > guess. > 2) How do we deal with unwanted access of shared parameters? This one > is not really controllable, is it? And we are talking about much more > than MaxBackends. This could perhaps be addressed with more > documentation in the headers for the concerned variables, as a first > step. Hm. Perhaps we should understand the full scope of the problem first. What else besides MaxBackends and the shared memory GUCs won't be properly initialized when the shared_preload_libraries' _PG_init() functions are called? MaxBackends seems to be the only one that folks have experienced problems with, which is why I initially zeroed in on it. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com