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 20220114025942.xl6no4bto6zqvnuj@jrouhaud
Whole thread Raw
In response to Re: [PATCH] Disable bgworkers during servers start in pg_upgrade  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Hi,

On Thu, Jan 13, 2022 at 06:44:12PM -0800, Andres Freund wrote:
> 
> The point is that we need the check for WAL writes / xid assignments / etc
> *either* way. There are ways extensions could trigger problems like e.g. xid
> assigned, besides bgworker doing stuff. Or postgres components doing so
> unintentionally.
> 
> Erroring out in situation where we *know* that there were concurrent changes
> unacceptable during pg_upgrade is always the right call. Such errors can be
> debugged and then addressed (removing the extension from s_p_l, fixing the
> extension, etc).
> 
> In contrast to that, preventing upgrades from succeeding because an extension
> has a dependency on bgworkers working, just because the bgworker *could* be
> doing something bad is different. The bgworker might never write, have a check
> for binary upgrade mode, etc. It may not be realistic to fix and extension to
> work without the bgworkers.
> 
> Imagine something like an table access method that has IO workers or such.

IIUC if a table access method has IO workers that starts doing writes quickly
(or any similar extension that *is* required to be present during upgrade but
that should be partially disabled), the only way to do a pg_upgrade would be to
make sure that the extension explicitly checks for the binary-upgrade mode and
don't do any writes, or provide a GUC for the same, since it should still
preloaded?  I'm fine with that, but that should probably be documented.
> 
> 
> > 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?
> 
> I still object to the approach of preventing bgworker registration. It doesn't
> provide much protection and might cause hard to address problems for some
> extensions.
> 
> I don't think I ever objected to preventing WAL-writes, I even proposed that
> upthread? Unless you suggest doing it specifically in bgworkers, rather than
> preventing similar problems outside bgworkers as well.

Sorry I missed that when re-reading the thread.  And no I'm not suggesting
preventing WAL writes in bgworkers only.

Since there's a clear consensus on how to fix the problem, I'm switching the
patch as Waiting on Author.



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [PATCH] Disable bgworkers during servers start in pg_upgrade
Next
From: Michael Paquier
Date:
Subject: Re: Refactoring of compression options in pg_basebackup