From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_upgrade --copy-file-range |
Date: | 2023-10-08 05:15:18 |
Message-ID: | CA+hUKGJvLLNQtzb=ZWcTsYF8kv8cR_=H17CX-eL8qNixeC4DAw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
Attachment | Content-Type | Size |
---|---|---|
v2-0001-Add-copy-file-range-option-to-pg_upgrade.patch | text/x-patch | 11.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michał Kłeczek | 2023-10-08 05:27:06 | Re: Draft LIMIT pushdown to Append and MergeAppend patch |
Previous Message | Laurenz Albe | 2023-10-08 04:14:12 | Re: Fix output of zero privileges in psql |