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

From Bruce Momjian
Subject Re: [PATCH] Disable bgworkers during servers start in pg_upgrade
Date
Msg-id 20210826143448.GD22637@momjian.us
Whole thread Raw
In response to Re: [PATCH] Disable bgworkers during servers start in pg_upgrade  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: [PATCH] Disable bgworkers during servers start in pg_upgrade
List pgsql-hackers
On Thu, Aug 26, 2021 at 03:59:49PM +0200, Daniel Gustafsson wrote:
> > On 26 Aug 2021, at 15:43, Julien Rouhaud <rjuju123@gmail.com> wrote:
> > 
> > Le jeu. 26 août 2021 à 21:38, Daniel Gustafsson <daniel@yesql.se <mailto:daniel@yesql.se>> a écrit :
> > > On 26 Aug 2021, at 15:09, Bruce Momjian <bruce@momjian.us <mailto:bruce@momjian.us>> wrote:
> > 
> > > Basically, pg_upgrade has avoided any backend changes that could be
> > > controlled by GUCs and I am not sure we want to start adding such
> > > changes for just this.
> > 
> > In principle I think it’s sound to try to avoid backend changes where possible
> > without sacrificing robustness.
> > 
> > I agree, but it seems quite more likely that an extension relying on a bgworker changes this guc, compared to an
extensionforcing autovacuum to be on for instance. 
 
> 
> Agreed, in this particular case I think there is merit to the idea of enforcing
> it in the backend.

OK, works for me

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  If only the physical world exists, free will is an illusion.




pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: Identify missing publications from publisher while create/alter subscription.
Next
From: vignesh C
Date:
Subject: Re: Printing backtrace of postgres processes