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

From: Denis Laxalde <denis(dot)laxalde(at)dalibo(dot)com>
To: Julien Rouhaud <rjuju123(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com>
Subject: Re: [PATCH] Disable bgworkers during servers start in pg_upgrade
Date: 2022-01-28 14:06:57
Message-ID: f135679a-9590-d81c-5d76-f9f4c3825d37@dalibo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Julien Rouhaud a écrit :
> I think having a new option for vacuumdb is the right move.
>
> It seems unlikely that any cron or similar on the host will try to run some
> concurrent vacuumdb, but we still have to enforce that only the one executed by
> pg_upgrade can succeed.
>
> I guess it could be an undocumented option, similar to postgres' -b, which
> would only be allowed iff --all and --freeze is also passed to be extra safe.

The help text in pg_dump's man page states:

--binary-upgrade
This option is for use by in-place upgrade
utilities. Its use for other purposes is not
recommended or supported. The behavior of
the option may change in future releases
without notice.

Is it enough? Or do we actually want to hide it for vacuumdb?

> While at it:
>
>> vacuumdb: error: processing of database "postgres" failed: PANIC: cannot
>> make new WAL entries during recovery
>
> Should we tweak that message when IsBinaryUpgrade is true?

Yes, indeed, I had in mind to simply make the message more generic as:
"cannot insert new WAL entries".

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2022-01-28 14:07:32 Re: Parameter for planner estimate of recursive queries
Previous Message Robert Haas 2022-01-28 13:57:42 Re: Unlogged relations and WAL-logging