Re: Emit a warning if the extension's GUC is set incorrectly

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: peter(dot)eisentraut(at)enterprisedb(dot)com
Cc: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Shinya11(dot)Kato(at)oss(dot)nttdata(dot)com, masao(dot)fujii(at)oss(dot)nttdata(dot)com, bharath(dot)rupireddyforpostgres(at)gmail(dot)com, daniel(at)yesql(dot)se, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Emit a warning if the extension's GUC is set incorrectly
Date: 2021-12-27 20:48:43
Message-ID: 1640909.1640638123@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> Concretely, I think we should do the attached, which removes much of
> 75d22069e and does the check at the point of placeholder creation.

I pushed that, and along the way moved the test case to be beside
the existing tests concerning custom GUC names, rather than appended
at the end of guc.sql as it had been. That turns out to make the
buildfarm very unhappy. I had not thought to test that change with
"force_parallel_mode = regress"; but with that on, we can see that
the warning (or now error) is reported each time a parallel worker
is launched, if the parent process contains a bogus placeholder.
So that accidentally unveiled another deficiency in the design of
the original patch --- we surely don't want that to happen.

As a stopgap to turn the farm green again, I am going to revert
75d22069e as well as my followup patches. If we don't want to
give up on that idea altogether, we have to find some way to
suppress the chatter from parallel workers. I wonder whether
it would be appropriate to go further than we have, and actively
delete placeholders that turn out to be within an extension's
reserved namespace. The core issue here is that workers don't
necessarily set GUCs and load extensions in the same order that
their parent did, so if we leave any invalid placeholders behind
after reserving an extension's prefix, we're risking issues
during worker start.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message kuroda.hayato@fujitsu.com 2021-12-27 23:57:15 RE: Allow escape in application_name
Previous Message Peter Eisentraut 2021-12-27 20:24:43 Re: sequences vs. synchronous replication