On Tue, Aug 24, 2021 at 04:40:02PM +0200, Denis Laxalde wrote: > Julien Rouhaud a écrit : >> I don't think that it would add that much complexity or overhead as there's >> already all the infrastructure to prevent WAL writes in certain condition. >> It >> should be enough to add an additional test in XLogInsertAllowed() with some >> new >> variable that is set when starting in binary upgrade mode, and a new function >> to disable it that will be emitted by pg_dump / pg_dumpall in binary upgrade >> mode. > > This part is less clear to me so I'm not sure I'd be able to work on it.
default_transaction_read_only brings in a certain level of safety, but
it is limited when it comes to operations involving maintenance like a
REINDEX or a VACUUM code path. Making use of a different way to
control if WAL should be allowed for binary upgrades with a new mean
looks like a more promising and more robust approach, even if that
means that any bgworkers started by the clusters on which the upgrade
is done would need to deal with any errors generated by this new
facility.
Saying that, I don't see a scenario where we'd need a bgworker to be
around during an upgrade. But perhaps some cloud providers have this
need in their own golden garden?
> @@ -5862,6 +5862,9 @@ do_start_bgworker(RegisteredBgWorker *rw)
> static bool
> bgworker_should_start_now(BgWorkerStartTime start_time)
> {
> + if (IsBinaryUpgrade)
> + return false;
> +
Using -c max_worker_processes=0 would just have the same effect, no?
So we could just patch pg_upgrade's server.c to get the same level of
protection?
--
Michael
signature.asc
Description: PGP signature
