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
