Re: pg_upgrade --clone error checking

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgrade --clone error checking
Date: 2019-05-02 18:03:23
Message-ID: CAMkU=1xyVxwT7ryRbZPj4CXnEuQhbsSASLeY0gxFacd9bGVAJw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 2, 2019 at 12:28 PM Alvaro Herrera <alvherre(at)2ndquadrant(dot)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

Attachment Content-Type Size
pg_upgrade_filesystem.patch application/octet-stream 1.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2019-05-02 18:06:14 Re: How to estimate the shared memory size required for parallel scan?
Previous Message Andres Freund 2019-05-02 17:28:51 Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6