From: Julien Rouhaud <rjuju123@gmail.com>
To: Denis Laxalde <denis.laxalde@dalibo.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@lists.postgresql.org, Jehan-Guillaume de Rorthais <jgdr@dalibo.com>
Subject: Re: [PATCH] Disable bgworkers during servers start in pg_upgrade
Date: Fri, 28 Jan 2022 21:56:36 +0800
Message-ID: <20220128135636.ls2zjbajirbdmrzb@jrouhaud> (raw)
In-Reply-To: <54f0d813-a38a-6b72-269a-7d6dd02bcc5b@dalibo.com>
References: <20210121152357.s6eflhqyh4g5e6dv@dalibo.com>
<20210124003611.lkyxhd2mpdmv5xzh@alap3.anarazel.de>
<20210127102511.tvhu2wmrxoz3tle4@dalibo.com>
<20210127144132.215fe4bb@firost>
<20210312082325.weltivlokfpc3gt2@nol>
<54f0d813-a38a-6b72-269a-7d6dd02bcc5b@dalibo.com>
Hi,
On Fri, Jan 28, 2022 at 11:02:46AM +0100, Denis Laxalde wrote:
>
> I tried that simple change first:
>
> diff --git a/src/backend/access/transam/xlog.c
> b/src/backend/access/transam/xlog.c
> index dfe2a0bcce..8feab0cb96 100644
> --- a/src/backend/access/transam/xlog.c
> +++ b/src/backend/access/transam/xlog.c
> @@ -8498,6 +8498,9 @@ HotStandbyActiveInReplay(void)
> bool
> XLogInsertAllowed(void)
> {
> + if (IsBinaryUpgrade)
> + return false;
> +
>
>
> But then, pg_upgrade's tests (make -C src/bin/pg_upgrade/ check) fail at
> vaccumdb but not during pg_dumpall:
>
> [...]
>
> command: "/home/denis/src/pgsql/build/tmp_install/home/denis/.local/pgsql/bin/vacuumdb"
> --host /home/denis/src/pgsql/build/src/bin/pg_upgrade --port 51696
> --username denis --all --analyze >> "pg_upgrade_utility.log" 2>&1
> vacuumdb: vacuuming database "postgres"
> vacuumdb: error: processing of database "postgres" failed: PANIC: cannot
> make new WAL entries during recovery
>
> In contrast with pg_dump/pg_dumpall, vacuumdb has no --binary-upgrade flag,
> so it does not seem possible to use a special GUC setting to allow WAL
> writes in that vacuumdb session at the moment.
> Should we add --binary-upgrade to vacuumdb as well? Or am I going in the
> wrong direction?
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.
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?
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: rjuju123@gmail.com, denis.laxalde@dalibo.com, andres@anarazel.de, jgdr@dalibo.com
Subject: Re: [PATCH] Disable bgworkers during servers start in pg_upgrade
In-Reply-To: <20220128135636.ls2zjbajirbdmrzb@jrouhaud>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox