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 f135679a-9590-d81c-5d76-f9f4c3825d37@dalibo.com
Whole thread Raw
In response to Re: [PATCH] Disable bgworkers during servers start in pg_upgrade  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: [PATCH] Disable bgworkers during servers start in pg_upgrade*
List pgsql-hackers
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?

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

Yes, indeed, I had in mind to simply make the message more generic as: 
"cannot insert new WAL entries".



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Unlogged relations and WAL-logging
Next
From: Robert Haas
Date:
Subject: Re: Parameter for planner estimate of recursive queries