Re: Mark all GUC variable as PGDLLIMPORT

From: Chapman Flack <chap(at)anastigmatix(dot)net>
To: Julien Rouhaud <rjuju123(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Mark all GUC variable as PGDLLIMPORT
Date: 2022-02-13 17:32:20
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


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;


&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.



In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Joseph Koshakow 2022-02-13 18:28:38 Fix overflow in justify_interval related functions
Previous Message Tom Lane 2022-02-13 17:13:17 Re: Adding CI to our tree