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