Re: [PATCH] Disable bgworkers during servers start in pg_upgrade - Mailing list pgsql-hackers

From Denis Laxalde
Subject Re: [PATCH] Disable bgworkers during servers start in pg_upgrade
Date
Msg-id 54f0d813-a38a-6b72-269a-7d6dd02bcc5b@dalibo.com
Whole thread Raw
In response to [PATCH] Disable bgworkers during servers start in pg_upgrade  (Denis Laxalde <denis.laxalde@dalibo.com>)
Responses Re: [PATCH] Disable bgworkers during servers start in pg_upgrade
List pgsql-hackers
Hi,

Julien Rouhaud a écrit :
>> On Wed, 27 Jan 2021 11:25:11 +0100
>> Denis Laxalde <denis.laxalde@dalibo.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



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Suppressing useless wakeups in walreceiver
Next
From: Greg Nancarrow
Date:
Subject: Re: row filtering for logical replication