Re: pg_upgrade --copy-file-range

On Mon, Jul 3, 2023 at 7:47 PM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
> When we added --clone, copy_file_range() was available, but the problem
> was that it was hard for the user to predict whether you'd get the fast
> clone behavior or the slow copy behavior. That's the kind of thing you
> want to know when planning and testing your upgrade. At the time, there
> were patches passed around in Linux kernel circles that would have been
> able to enforce cloning via the flags argument of copy_file_range(), but
> that didn't make it to the mainline.
>
> So, yes, being able to specify exactly which copy mechanism to use makes
> sense, so that users can choose the tradeoffs.

Thanks for looking. Yeah, it is quite inconvenient for planning
purposes that it is hard for a user to know which internal strategy it
uses, but that's the interface we have (and clearly "flags" is
reserved for future usage so that might still evolve..).

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