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

From Peter Eisentraut
Subject Re: pg_upgrade --copy-file-range
Date
Msg-id eb170058-b6cc-41fa-a498-da604b13601c@eisentraut.org
Whole thread Raw
In response to Re: pg_upgrade --copy-file-range  (Jakub Wartak <jakub.wartak@enterprisedb.com>)
Responses Re: pg_upgrade --copy-file-range
List pgsql-hackers
On 05.01.24 13:40, Jakub Wartak wrote:
> Random patch notes:
> - main meat is in v3-0002*, I hope i did not screw something seriously
> - in worst case: it is opt-in through switch, so the user always can
> stick to the classic copy
> - no docs so far
> - pg_copyfile_offload_supported() should actually be fixed if it is a
> good path forward
> - pgindent actually indents larger areas of code that I would like to,
> any ideas or is it ok?
> - not tested on Win32/MacOS/FreeBSD
> - i've tested pg_upgrade manually and it seems to work and issue
> correct syscalls, however some tests are failing(?). I haven't
> investigated why yet due to lack of time.

Something is wrong with the pgindent in your patch set.  Maybe you used 
a wrong version.  You should try to fix that, because it is hard to 
process your patch with that amount of unrelated reformatting.

As far as I can tell, the original pg_upgrade patch has been ready to 
commit since October.  Unless Thomas has any qualms that have not been 
made explicit in this thread, I suggest we move ahead with that.

And then Jakub could rebase his patch set on top of that.  It looks like 
if the formatting issues are fixed, the remaining pg_combinebackup 
support isn't that big.




pgsql-hackers by date:

Previous
From: Aleksander Alekseev
Date:
Subject: Re: Preserve subscription OIDs during pg_upgrade
Next
From: Japin Li
Date:
Subject: Re: Improve readability by using designated initializers when possible