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 20220112095431.u3puwgdbfnt2c7bv@jrouhaud
Whole thread Raw
In response to Re: [PATCH] Disable bgworkers during servers start in pg_upgrade  (Michael Paquier <michael@paquier.xyz>)
Responses Re: [PATCH] Disable bgworkers during servers start in pg_upgrade
List pgsql-hackers
On Sat, Aug 28, 2021 at 10:40:42AM +0900, Michael Paquier wrote:
> On Fri, Aug 27, 2021 at 12:28:42PM -0700, Andres Freund wrote:
> > Isn't that just going to end up with extension code erroring out and/or
> > blocking waiting for a bgworker to start?
> 
> Well, that's the point to block things during an upgrade.  Do you have
> a list of requirements you'd like to see satisfied here?  POWA would
> be fine with blocking the execution of bgworkers AFAIK (Julien feel
> free to correct me here if necessary).  It could be possible that
> preventing extension code to execute this way could prevent hazards as
> well.  The idea from upthread to prevent any writes and/or WAL
> activity is not really different as extensions may still generate an
> error because of pg_upgrade's safety measures we'd put in, no?

This thread is now almost one year old, and AFAICT there's still no consensus
on how to fix this problem.  It would be good to have something done in pg15,
ideally backpatched, as this is a corruption hazard that triggered at least
once already.

Andres, do you still have an objection with either preventing bgworker
registration/launch or WAL-write during the impacted pg_upgrade steps, or a
better alternative to fix the problem?



pgsql-hackers by date:

Previous
From: Andrey Borodin
Date:
Subject: Re: libpq compression (part 2)
Next
From: Peter Eisentraut
Date:
Subject: Re: small bug in ecpg unicode identifier error handling