Re: Mark all GUC variable as PGDLLIMPORT

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: 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 07:29:31
Message-ID: 20220213072931.dxfdumusodlrkxyf@jrouhaud
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Sat, Feb 12, 2022 at 07:59:56PM -0800, Andres Freund wrote:
>
> On 2021-08-23 14:53:34 +0800, Julien Rouhaud wrote:
> > So since the non currently explicitly exported GUC global variables shouldn't
> > be accessible by third-party code, I'm attaching a POC patch that does the
> > opposite of v1: enforce that restriction using a new pg_attribute_hidden()
> > macro, defined with GCC only, to start discussing that topic.
>
> This fails on cfbot: https://cirrus-ci.com/task/6424663592009728?logs=build#L1
>
> I'm not feeling a lot of enthusiasm for the change.

Yes, which is also why I'm not planning on spending more effort on that (or the
opposite) unless I get some sort of feedback, so thanks a lot for the answer
here.

Note that if everyone is happy with the status quo please say so. I will
happily mark the CF entry rejected and stop all efforts to try packaging
extensions on Windows. It will save me a lot of efforts that 99% of users
don't care about.

If not maybe we could improve the situation, and also learn for the max_backend
thread.

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?

> But if we were to do this,
> we'd have to have infrastructure to detect missing hidden declarations,
> otherwise it's inevitable that they don't get added.

Agreed. For now I'm using a simple loop around

egrep "^\s+&[A-Za-z_]+,$" src/backend/utils/misc/guc.c | egrep -o "[A-Za-z_]+"

to get all the underlying symbols, and grep that again (actually using ag,
which makes it 3x faster) to detect the lack of wanted annotation. Were you
thinking of some script like that, maybe to run before a release, or something
more evolved?

> I kind of like the idea of hiding postgres symbols for other reasons than
> win<->everything else parity. Namely that not exporting symbols can allow the
> compiler to optimize more...

Yeah I saw that in nearby threads and I entirely agree.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2022-02-13 08:13:23 Consistently use "startup process"/"WAL sender" instead of "Startup process"/"WAL Sender" in comments and docs.
Previous Message Dilip Kumar 2022-02-13 06:34:16 Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints