Subject: Re: Mark all GUC variable as PGDLLIMPORT
To: Julien Rouhaud <rjuju123@gmail.com>, Andres Freund <andres@anarazel.de>
References: <20210822081033.kx6op325sbd24cw5@nol>
 <YSI6PqeRxJ8HpbtC@paquier.xyz> <20210822120743.lvazjchtns5sezb2@nol>
 <2210220.1629638382@sss.pgh.pa.us> <20210822132901.ztlervolfdbqypw4@nol>
 <20210823065334.6jpx4ux7l2maggvf@nol>
 <20220213035956.bi6xumusrcog5wsb@alap3.anarazel.de>
 <20220213072931.dxfdumusodlrkxyf@jrouhaud>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael@paquier.xyz>,
 pgsql-hackers@lists.postgresql.org
From: Chapman Flack <chap@anastigmatix.net>
Message-ID: <620940A4.5010900@anastigmatix.net>
Date: Sun, 13 Feb 2022 12:32:20 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <20220213072931.dxfdumusodlrkxyf@jrouhaud>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/620940A4.5010900%40anastigmatix.net>
Precedence: bulk

Hi,

On 02/13/22 02:29, Julien Rouhaud wrote:
> Maybe we could have an actually usable GUC API to retrieve values in their
> native format rather than C string for instance, that we could make sure also
> works for cases like max_backend?

I proposed a sketch of such an API for discussion back in [0] (the second
idea in that email, the "what I'd really like" one).

In that scheme, some extension code that was interested in (say,
for some reason) log_statement_sample_rate could say:

static double samprate;
static int gucs_changed = 0;

#define SAMPRATE_CHANGED 1

...
  ObserveTypedConfigValue("log_statement_sample_rate",
    &samprate, &gucs_changed, SAMPRATE_CHANGED);
...

and will be subscribed to have the native-format value stored into samprate,
and SAMPRATE_CHANGED ORed into gucs_changed, whenever the value changes.

The considerations leading me to that design were:

- avoid subscribing as a 'callback' sort of listener. GUCs can get set
  (or, especially, reset) in delicate situations like error recovery
  where calling out to arbitrary extra code might best be avoided.

- instead, just dump the value in a subscribed location. A copy,
  of course, so no modification there affects the real value.

- but at the same time, OR a flag into a bit set, so subscribing code can
  very cheaply poll for when a value of interest (or any of a bunch of
  values of interest) has changed since last checked.

- do the variable lookup by name once only, and pay no further search cost
  when the subscribing code wants the value.


I never pictured that proposal as the last word on the question, and
different proposals could result from putting different weights on those
objectives, or adding other objectives, but I thought it might serve
as a discussion-starter.

Regards,
-Chap


[0] https://www.postgresql.org/message-id/6123C425.3080409%40anastigmatix.net