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 1nehlX-0001Iy-R2 for pgsql-hackers@arkaria.postgresql.org; Wed, 13 Apr 2022 18:30:55 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nehlV-0003GK-QB for pgsql-hackers@arkaria.postgresql.org; Wed, 13 Apr 2022 18:30:53 +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 1nehlV-0003GB-Gp for pgsql-hackers@lists.postgresql.org; Wed, 13 Apr 2022 18:30:53 +0000 Received: from mail-pj1-x1032.google.com ([2607:f8b0:4864:20::1032]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nehlN-0003Ni-J9 for pgsql-hackers@lists.postgresql.org; Wed, 13 Apr 2022 18:30:51 +0000 Received: by mail-pj1-x1032.google.com with SMTP id mm4-20020a17090b358400b001cb93d8b137so7058079pjb.2 for ; Wed, 13 Apr 2022 11:30:45 -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=AWhSkcra3eVIo9+aZIZl/EVyA16wmPwjBxDQrdowh50=; b=cDJQWGENjYJSpW4JGXxnsf6gd9n/7vcxlvMy10MerM9FCZD2lQ4gYDiPp5R74sNGnk crnrx4/DE4fir/maIlXb9XvLB/tt8bnmMFGrC8abq3qN9T/GzfrmIoc0JQhZui8JjwS+ Fh1uBJw+WyS4XbQCenjeU/D9YvEjZXK2Os46O1JP1l5Ajystb7smaxcpl4P988SM76AR mNrvq16GLbGd52RAq8KO5wezDu4+gmprzDyr7vwcl9JhH2VkhWcwSSGGUlPdldb6dsuD RWybGbDOr26XCm/jzkpaCXj9EQh3Vjom+xL9/4ecbJ7GS/JVfABupKvvb+oAgffHM1Ie YT2g== 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=AWhSkcra3eVIo9+aZIZl/EVyA16wmPwjBxDQrdowh50=; b=K7y/9A3x/1tXU2zU7l9T2I4Lg6UjMITyuTQXMP+AqEL3j6JtxPLw3OWdBwf7ZGPT+y jGEK+7Fn9GrAV05fArftNFT9u4xl+dWVEY+uGT9qyjdY/JyMpPjnCwhXwSZHDJUkJ8+r CKtwl1HuvVOi8V4otnxj+QvQrDGV2XcyO8QAA6zVY8l4EONl3NUYGTkhgME6MF4TeY4w ZNAtVV7GSiwIitjm12Lsk/33K64WhxoWprK1x7Xx+mdoxeLdUxzSEhmyLvK0cpp/Pmn/ aJjRXdgHpOGkOL0OiI1HSh4qB/KpmCC6nazzGEi+uBkhpK2zkBJbhBzgQkcjvluV42As VhxQ== X-Gm-Message-State: AOAM5333+dFjVh/Pak8AA8Hljt5bnyuz3EUPo1/yuWO7KAlodK3sOol0 NGxFLrgk0uvx9n14dSFsNCE= X-Google-Smtp-Source: ABdhPJw7uO3MjAUZnJX0/UMc52BMJ88AbKrzOPW/NuxvdTrGp7MbevliEZDtsEwrM4TT7HhJVX9OkA== X-Received: by 2002:a17:90a:be16:b0:1cd:5aef:69e8 with SMTP id a22-20020a17090abe1600b001cd5aef69e8mr28452pjs.233.1649874643566; Wed, 13 Apr 2022 11:30:43 -0700 (PDT) Received: from nathanxps13 ([50.54.155.70]) by smtp.gmail.com with ESMTPSA id s3-20020a056a00194300b004f6664d26eesm46743148pfk.88.2022.04.13.11.30.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Apr 2022 11:30:42 -0700 (PDT) Date: Wed, 13 Apr 2022 11:30:40 -0700 From: Nathan Bossart To: Tom Lane Cc: Robert Haas , 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: <20220413183040.GA2116671@nathanxps13> References: <995617.1649799996@sss.pgh.pa.us> <20220412222616.GA2113503@nathanxps13> <1088297.1649856441@sss.pgh.pa.us> <1095139.1649860995@sss.pgh.pa.us> <1100207.1649864342@sss.pgh.pa.us> <1102589.1649865908@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1102589.1649865908@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Apr 13, 2022 at 12:05:08PM -0400, Tom Lane wrote: > Robert Haas writes: >> It may be too much to hope that we're going to completely get rid of >> process_shared_preload_libraries_in_progress tests. > > Perhaps, but this is definitely an area that could stand to have some > serious design thought put into it. You're quite right that it's > largely a mess today, but I think proposals like "forbid setting GUCs > during _PG_init" would add to the mess rather than clean things up. +1. The simplest design might be to just make a separate preload hook. _PG_init() would install hooks, and then this preload hook would do anything that needs to happen when the library is loaded via s_p_l. However, I think we still want a new shmem request hook where MaxBackends is initialized. If we do move forward with the shmem request hook, do we want to disallow shmem requests anywhere else, or should we just leave it up to extension authors to do the right thing? Many shmem requests in _PG_init() are probably okay unless they depend on MaxBackends or another GUC that someone might change. Given that, I think I currently prefer the latter (option B from upthread). -- Nathan Bossart Amazon Web Services: https://aws.amazon.com