Re: [PATCH] Disable bgworkers during servers start in pg_upgrade
От | Denis Laxalde |
---|---|
Тема | Re: [PATCH] Disable bgworkers during servers start in pg_upgrade |
Дата | |
Msg-id | 54f0d813-a38a-6b72-269a-7d6dd02bcc5b@dalibo.com обсуждение исходный текст |
Ответ на | [PATCH] Disable bgworkers during servers start in pg_upgrade (Denis Laxalde <denis.laxalde@dalibo.com>) |
Ответы |
Re: [PATCH] Disable bgworkers during servers start in pg_upgrade
|
Список | 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 по дате отправления: