Re: pg_upgrade --copy-file-range - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: pg_upgrade --copy-file-range
Date
Msg-id CA+hUKGLK98mY=GapDY7k816PkUmaCC66StnfvDhBOjMKxQp8FQ@mail.gmail.com
Whole thread Raw
In response to Re: pg_upgrade --copy-file-range  (Peter Eisentraut <peter@eisentraut.org>)
Responses Re: pg_upgrade --copy-file-range
List pgsql-hackers
On Sat, Dec 23, 2023 at 9:40 AM Peter Eisentraut <peter@eisentraut.org> wrote:
> On 13.11.23 08:15, Peter Eisentraut wrote:
> > On 08.10.23 07:15, Thomas Munro wrote:
> >>> About your patch:
> >>>
> >>> I think you should have a "check" function called from
> >>> check_new_cluster().  That check function can then also handle the "not
> >>> supported" case, and you don't need to handle that in
> >>> parseCommandLine().  I suggest following the clone example for these,
> >>> since the issues there are very similar.
> >>
> >> Done.
> >
> > This version looks good to me.
> >
> > Tiny nit:  You copy-and-pasted "%s/PG_VERSION.clonetest"; maybe choose a
> > different suffix.
>
> Thomas, are you planning to proceed with this patch?

Yes.  Sorry for being slow... got stuck working on an imminent new
version of streaming read.  I will be defrosting my commit bit and
committing this one and a few things shortly.

As it happens I was just thinking about this particular patch because
I suddenly had a strong urge to teach pg_combinebackup to use
copy_file_range.  I wonder if you had the same idea...



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: pg_upgrade --copy-file-range
Next
From: Peter Eisentraut
Date:
Subject: Re: Set all variable-length fields of pg_attribute to null on column drop