From: Nathan Bossart <nathandbossart@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: Bossart, Nathan <bossartn@amazon.com>
Cc: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: wangsh.fnst@fujitsu.com <wangsh.fnst@fujitsu.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: Greg Sabino Mullane <htamfids@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org <pgsql-hackers@lists.postgresql.org>
Subject: Re: make MaxBackends available in _PG_init
Date: Tue, 1 Feb 2022 14:36:40 -0800
Message-ID: <20220201223640.GA739804@nathanxps13> (raw)
In-Reply-To: <CA+TgmoY-fKi-q8pr_fAo_E2iiXzvwFK=MEvq7Hy21voKo99zDA@mail.gmail.com>
References: <01c32f6c-8101-1ce4-8295-534cf067df94@oss.nttdata.com>
<7239E4F9-A46D-4A61-9200-8B1366D03ADB@amazon.com>
<CA+TgmoZoyOKcE4TpAExHNSvfwE8Q_Y-tDvASN783Zb870pwKAA@mail.gmail.com>
<1E960D8B-24D7-43E0-9744-C5F8C52DDEB4@amazon.com>
<Ye+uOIE0TSbHf/FF@paquier.xyz>
<B6186047-CB98-49B1-A2CA-959057703788@amazon.com>
<YfHtpO9+pxsHblmX@paquier.xyz>
<20220127181815.GA551692@nathanxps13>
<YfSkID0m1APm3ZGr@paquier.xyz>
<CA+TgmoY-fKi-q8pr_fAo_E2iiXzvwFK=MEvq7Hy21voKo99zDA@mail.gmail.com>
On Mon, Jan 31, 2022 at 09:32:21AM -0500, Robert Haas wrote:
> The main reason why this doesn't work for MaxBackends is that
> MaxBackends depends on the values of multiple GUCs. There is a further
> wrinkle too, which is that none of those GUCs can change, and
> therefore code does things with the resulting value on the assumption
> that they won't change, like size shared-memory data structures.
> Therefore, if you read the wrong value, you've got a big problem. So
> the real issues here IMHO are about the difficulty of making sure that
> (1) when a GUC changes, we update all of the things that depend on it
> including things which may also depend on other GUCs and (2) making
> sure that values which can't ever change are computed before they are
> used.
>
> I don't know what the solution to problem #1 is, but the solution to
> problem #2 is simple: make people call a function to get the value
> rather than just reading a bare variable. GetConfigOption() is not a
> good solution for people aiming to write C code that does useful
> things, because it delivers the value as a string, and that is not
> what you want. But an accessor function like GetMaxBackends() for a
> quantity of this type is wonderful. Depending on the situation, you
> might choose to have the accessor function [a] fail an assertion if
> the value is not available yet or [b] compute the value if they value
> has not yet been computed or [c] do the latter if possible, otherwise
> the former. But the fact that you are making code call a function
> rather than just read a variable gives you a very strong tool to make
> sure that someone can't blindly read a 0 or whatever instead of the
> real value.
+1
I can work on a new patch if this is the direction we want to go. There
were a couple of functions that called GetMaxBackends() repetitively that I
should probably fix before the patch should be seriously considered.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: nathandbossart@gmail.com, robertmhaas@gmail.com, michael@paquier.xyz, bossartn@amazon.com, masao.fujii@oss.nttdata.com, wangsh.fnst@fujitsu.com, andres@anarazel.de, bharath.rupireddyforpostgres@gmail.com, htamfids@gmail.com, tgl@sss.pgh.pa.us, pgsql-hackers@lists.postgresql.org
Subject: Re: make MaxBackends available in _PG_init
In-Reply-To: <20220201223640.GA739804@nathanxps13>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox