Re: pg_upgrade --clone error checking

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: pg_upgrade --clone error checking
Дата
Msg-id CAMkU=1xyVxwT7ryRbZPj4CXnEuQhbsSASLeY0gxFacd9bGVAJw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_upgrade --clone error checking  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: pg_upgrade --clone error checking  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список pgsql-hackers
Дерево обсуждения

On Thu, May 2, 2019 at 12:28 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
On 2019-May-02, Jeff Janes wrote:

>
> When something is doomed to fail, we should report the failure as early as
> feasibly detectable.

I agree -- this check should be done before checking the database
contents.  Maybe even before "Checking cluster versions".

It looks like it was designed for early checking, it just wasn't placed early enough.  So changing it is pretty easy, as check_file_clone does not need to be invented, and there is no additional code duplication over what was already there.

This patch moves the checking to near the beginning.

It carries the --link mode checking along with it.  That should be done as well, and doing it as a separate patch would make both patches uglier.

Cheers,

Jeff
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: REINDEX INDEX results in a crash for an index of pg_class since9.6
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: How to estimate the shared memory size required for parallel scan?