Re: Mark all GUC variable as PGDLLIMPORT - Mailing list pgsql-hackers

From John Naylor
Subject Re: Mark all GUC variable as PGDLLIMPORT
Date
Msg-id CAFBsxsGAYmA0bOdRiW4dW4pLsa0h4P1+YVMMkajzKFpUrYXs9g@mail.gmail.com
Whole thread Raw
In response to Re: Mark all GUC variable as PGDLLIMPORT  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Mark all GUC variable as PGDLLIMPORT  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On Tue, Apr 5, 2022 at 10:06 PM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Tue, Apr 5, 2022 at 10:07 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Yeah, the frontend error message rework in [1].  That has exactly
> > the same constraint that it's likely to break other open patches,
> > so it'd be better to do it after the CF cutoff.  I think that doing
> > that concurrently with Robert's thing shouldn't be too risky, because
> > it only affects frontend code while his patch should touch only backend.
>
> So when *exactly* do we want to land these patches? None of the
> calendar programs I use support "anywhere on earth" as a time zone,
> but I think that feature freeze is 8am on Friday on the East coast of
> the United States.

I understand it to be noon UTC on Friday.

> If I commit the PGDLLIMPORT change within a few
> hours after that time, is that good? Should I try to do it earlier,
> before we technically hit 8am? Should I do it the night before, last
> thing before I go to bed on Thursday? Do you care whether your commit
> or mine goes in first?

For these two patches, I'd say a day or two after feature freeze is a
reasonable goal.

--
John Naylor
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Add index scan progress to pg_stat_progress_vacuum
Next
From: Alvaro Herrera
Date:
Subject: Re: LogwrtResult contended spinlock