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

On Fri, Jan 28, 2022 at 9:51 PM Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:
> On Fri, Jan 28, 2022 at 10:20:07AM -0800, Andres Freund wrote:
> > On 2022-01-28 21:56:36 +0800, Julien Rouhaud wrote:
> > > I think having a new option for vacuumdb is the right move.
> >
> > Can't we pass the option via the connection string, e.g. something
> > PGOPTIONS='-c binary_upgrade_mode=true'? That seems to scale better than to
> > add it gradually to multiple tools.
>
> Ah right that's a better idea.

OK, so I think the conclusion here is that no patch which does
$SUBJECT is going to get committed, but somebody might write (or
finish?) a patch that does something else which could possibly get
committed once it's written. If and when that happens, I think that
patch should be submitted on a new thread with a subject line that
matches what the patch actually does. In the meantime, I'm going to
mark the CF entry for *this* thread as Returned with Feedback.

For what it's worth, I'm not 100% sure that $SUBJECT is a bad idea --
nor am I 100% sure that it's a good idea. On the other hand, I
definitely think the alternative proposal of blocking WAL writes at
times when they shouldn't be happening is a good idea, and most likely
extensions should also be coded in a way where they're smart enough
not to try except at times when it is safe. Therefore, it make sense
to me to proceed along those kinds of lines for now, and if that's not
enough and we need to revisit this idea at some point in the future,
we can.

Note that I'm taking no view for the present on whether any change
that might end up being agreed here should go into v15 or not. It's in
that fuzzy grey area where you could call it a feature, or a bug fix,
or technically-a-feature-but-let's-slip-it-in-after-freeze-anyway. We
can decide that when a completed patch shows up, though it's fair to
point out that the longer that takes, the less likely it is to be v15
material. I am, however, taking the position that holding this
CommitFest entry open is not in the best interest of the project. The
patch we'd theoretically be committing doesn't exist yet and doesn't
do what the subject line suggests.

Thanks,

--
Robert Haas
EDB: http://www.enterprisedb.com