From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
---|---|
To: | Denis Laxalde <denis(dot)laxalde(at)dalibo(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:18:28 |
Message-ID: | 20220128141828.sl7alufb2odg26c3@jrouhaud |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jan 28, 2022 at 03:06:57PM +0100, Denis Laxalde wrote:
> 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?
I think it should be hidden, with a comment about it like postmaster.c getopt
call:
case 'b':
/* Undocumented flag used for binary upgrades */
> > > 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".
-1, it's good to have a clear reason why the error happened, especially since
it's supposed to be "should not happen" situation.
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2022-01-28 14:30:02 | Re: Support for NSS as a libpq TLS backend |
Previous Message | Bharath Rupireddy | 2022-01-28 14:10:02 | Remove extra includes of "access/xloginsert.h" when "access/xlog.h" is included |