Re: [PATCH] Disable bgworkers during servers start in pg_upgrade

Поиск
Список
Период
Сортировка
От Denis Laxalde
Тема Re: [PATCH] Disable bgworkers during servers start in pg_upgrade
Дата
Msg-id f135679a-9590-d81c-5d76-f9f4c3825d37@dalibo.com
обсуждение исходный текст
Ответ на Re: [PATCH] Disable bgworkers during servers start in pg_upgrade  (Julien Rouhaud <rjuju123@gmail.com>)
Ответы Re: [PATCH] Disable bgworkers during servers start in pg_upgrade*  (Julien Rouhaud <rjuju123@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Unlogged relations and WAL-logging
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Parameter for planner estimate of recursive queries