Re: pg_upgrade --copy-file-range
От | Thomas Munro |
---|---|
Тема | Re: pg_upgrade --copy-file-range |
Дата | |
Msg-id | CA+hUKGLK98mY=GapDY7k816PkUmaCC66StnfvDhBOjMKxQp8FQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_upgrade --copy-file-range (Peter Eisentraut <peter@eisentraut.org>) |
Ответы |
Re: pg_upgrade --copy-file-range
|
Список | 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 по дате отправления: