Re: [PATCH] Disable bgworkers during servers start in pg_upgrade - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: [PATCH] Disable bgworkers during servers start in pg_upgrade
Date
Msg-id CAOBaU_aSSbmR8OcJ_jP9QQz5kYewp78jFGF8E=9FKt1V-At7qg@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Disable bgworkers during servers start in pg_upgrade  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Sat, Aug 28, 2021 at 3:28 AM Andres Freund <andres@anarazel.de> wrote:
>
> > On Fri, Aug 27, 2021 at 7:31 AM Michael Paquier <michael@paquier.xyz> wrote:
> >
> > > Wouldn't it be better to block things at the source, as of
> > > RegisterBackgroundWorker()?  And that would keep track of the control
> > > we have on bgworkers in a single place.  I also think that we'd better
> > > document something about that either in bgworker.sgml or pg_upgrade's
> > > page.
>
> Isn't that just going to end up with extension code erroring out and/or
> blocking waiting for a bgworker to start?

But there's no API to wait for the start of a non-dynamic bgworker or
check for it right?  So I don't see how the extension code could wait
or error out.  As far as I know the only thing you can do is
RegisterBackgroundWorker() in your _PG_init() code and hope that the
server is correctly configured.  The only thing that third-party code
could I think is try to check if the bgworker could be successfully
registered or not as I mentioned in [1].  Maybe extra paranoid code
may add such check in all executor hook but the overhead would be so
terrible that no one would use such an extension anyway.

[1] https://www.postgresql.org/message-id/CAOBaU_ZtR88x3Si6XwprqGo8UZNLncAQrD_-wc67sC=acO3g=w@mail.gmail.com



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [PATCH] Disable bgworkers during servers start in pg_upgrade
Next
From: Julien Rouhaud
Date:
Subject: Re: [PATCH] Disable bgworkers during servers start in pg_upgrade