Re: Mark all GUC variable as PGDLLIMPORT

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Mark all GUC variable as PGDLLIMPORT
Date: 2021-08-23 18:48:35
Message-ID: CAH2-Wznt2bW8XRV7fEij1YAQcb5Q-nwCWpDv0Rdd6pKMPjaUEQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Aug 23, 2021 at 7:57 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> In short, +1 from me for the original proposal of marking all GUCs as
> PGDLLIMPORT.

+1

> And, heck, +1 for marking all the other global variables
> that way, too. We're not solving any problem here. We're just annoying
> people, mostly people who are loyal community members and steady
> contributors to the project.

I'm +0.5 on this aspect -- the result might be a lot of verbosity for
no possible benefit.

I'm not sure how many global variables there are. Hopefully not that
many. Maybe making adding new global variables annoying would be a
useful disincentive -- sometimes we use global variables when it isn't
particularly natural (it's natural with GUCs, but not other things).
That might tip the scales, at least for me.

Unnecessary use of global variables are why Postgres 13 went through
several point releases before I accidentally found out that parallel
VACUUM doesn't respect cost limits -- a very simple bug concerning how
we propagate (or fail to propagate) state to parallel workers. I bet
it would have taken far longer for the bug to be discovered if it
wasn't for my Postgres 14 VACUUM refactoring work.

--
Peter Geoghegan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2021-08-23 18:48:54 Re: [PROPOSAL] new diagnostic items for the dynamic sql
Previous Message Platon Pronko 2021-08-23 18:46:57 Re: very long record lines in expanded psql output