Re: [PATCH] Disable bgworkers during servers start in pg_upgrade

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: [PATCH] Disable bgworkers during servers start in pg_upgrade
Дата
Msg-id 20220114024412.4j3bz4gzdjgnhcw4@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: [PATCH] Disable bgworkers during servers start in pg_upgrade  (Julien Rouhaud <rjuju123@gmail.com>)
Ответы Re: [PATCH] Disable bgworkers during servers start in pg_upgrade  (Julien Rouhaud <rjuju123@gmail.com>)
Список pgsql-hackers
Hi,

On 2022-01-12 17:54:31 +0800, Julien Rouhaud wrote:
> 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?

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.


> 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.

Greetings,

Andres Freund



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Julien Rouhaud
Дата:
Сообщение: Re: Schema variables - new implementation for Postgres 15
Следующее
От: Julien Rouhaud
Дата:
Сообщение: Re: [PATCH] Disable bgworkers during servers start in pg_upgrade