Horton

Re: Mark all GUC variable as PGDLLIMPORT

Julien Rouhaud <rjuju123@gmail.com>

View thread View on postgr.es
From: Julien Rouhaud <rjuju123@gmail.com>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Chapman Flack <chap@anastigmatix.net>, Robert Haas <robertmhaas@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Tom Lane <tgl@sss.pgh.pa.us>, Bruce Momjian <bruce@momjian.us>, Michael Paquier <michael@paquier.xyz>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-08-24T04:58:37Z
Lists: pgsql-hackers 
On Tue, Aug 24, 2021 at 12:36 PM Pavel Stehule <pavel.stehule@gmail.com> wrote:
>
> There are few GUC variables, where we need extra fast access - work_mem, encoding settings, and maybe an application name. For others I hadn't needed to access it for over 20 years. But I understand that more complex extensions like timescaledb will use more internal GUC.

Note that even trivial extensions require some other GUC access.  For
instance any single extension that wants to aggregate data based on
the query_id has to store an array of query_id in shmem to know what a
parallel worker is working on.  On top of wasting memory and CPU, it
also means that computing the maximum number of backends in required.
So you need to recompute MaxBackends, which means access to multiple
GUCs.

Unfortunately the patch to expose the query_id didn't fix that problem
as it only passes the top level query_id to the pararllel workers, not
the current one.

Commits

  1. Remove PGDLLIMPORT marker from __pg_log_level

  2. Mark a few 'bbsink' related functions / variables static.

  3. Add some missing PGDLLIMPORT markings

  4. Apply PGDLLIMPORT markings broadly.

  5. Helper script to apply PGDLLIMPORT markings.

  6. Simplify declaring variables exported from libpgcommon and libpgport.