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>, Andres Freund <andres(at)anarazel(dot)de>
Cc: 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 10:02:46
Message-ID: 54f0d813-a38a-6b72-269a-7d6dd02bcc5b@dalibo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Julien Rouhaud a écrit :
>> On Wed, 27 Jan 2021 11:25:11 +0100
>> Denis Laxalde <denis(dot)laxalde(at)dalibo(dot)com> wrote:
>>
>>> Andres Freund a écrit :
>>>> b) when in binary upgrade mode / -b, error out on all wal writes in
>>>> sessions that don't explicitly set a session-level GUC to allow
>>>> writes.

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

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;
+
/*
* If value is "unconditionally true" or "unconditionally
false", just
* return it. This provides the normal fast path once recovery
is known

But then, pg_upgrade's tests (make -C src/bin/pg_upgrade/ check) fail at
vaccumdb but not during pg_dumpall:

$ cat src/bin/pg_upgrade/pg_upgrade_utility.log
-----------------------------------------------------------------
pg_upgrade run on Fri Jan 28 10:37:36 2022
-----------------------------------------------------------------

command:
"/home/denis/src/pgsql/build/tmp_install/home/denis/.local/pgsql/bin/pg_dumpall"
--host /home/denis/src/pgsql/build/src/bin/pg_upgrade --port 51696
--username denis --globals-only --quote-all-identifiers --binary-upgrade
-f pg_upgrade_dump_globals.sql >> "pg_upgrade_utility.log" 2>&1

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?

Thanks,
Denis

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Nancarrow 2022-01-28 10:06:45 Re: row filtering for logical replication
Previous Message Thomas Munro 2022-01-28 09:41:32 Re: Suppressing useless wakeups in walreceiver