Re: CREATE DATABASE with filesystem cloning - Mailing list pgsql-hackers
From | Nazir Bilal Yavuz |
---|---|
Subject | Re: CREATE DATABASE with filesystem cloning |
Date | |
Msg-id | CAN55FZ3+goQy1so6Sz9u0dRoO-MEHTq5=RCxE=KsiLLvG7gYhg@mail.gmail.com Whole thread Raw |
In response to | Re: CREATE DATABASE with filesystem cloning (Ranier Vilela <ranier.vf@gmail.com>) |
Responses |
Re: CREATE DATABASE with filesystem cloning
|
List | pgsql-hackers |
Hi, On Tue, 21 May 2024 at 15:08, Ranier Vilela <ranier.vf@gmail.com> wrote: > > Em ter., 21 de mai. de 2024 às 05:18, Nazir Bilal Yavuz <byavuz81@gmail.com> escreveu: >> >> Hi, >> >> On Thu, 16 May 2024 at 17:47, Robert Haas <robertmhaas@gmail.com> wrote: >> > >> > On Thu, May 16, 2024 at 9:43 AM Nazir Bilal Yavuz <byavuz81@gmail.com> wrote: >> > > Actually, the documentation for the file_copy_method was mentioning >> > > the things it controls; I converted it to an itemized list now. Also, >> > > changed the comment to: 'Further uses of this function requires >> > > updates to the list that GUC controls in its documentation.'. v7 is >> > > attached. >> > >> > I think the comments need some wordsmithing. >> >> I changed it to 'Uses of this function must be documented in the list >> of places affected by this GUC.', I am open to any suggestions. >> >> > I don't see why this parameter should be PGC_POSTMASTER. >> >> I changed it to 'PGC_USERSET' now. My initial point was the database >> or tablespace to be copied with the same method. I thought copying >> some portion of the database with the copy and rest with the clone >> could cause potential problems. After a bit of searching, I could not >> find any problems related to that. >> >> v8 is attached. > > Hi, > I did some research on the subject and despite being an improvement, > I believe that some terminologies should be changed in this patch. > Although the new function is called *clone_file*, I'm not sure if it really is "clone". > Why MacOS added an API called clonefile [1] and Linux exists > another called FICLONE.[2] > So perhaps it should be treated here as a copy and not a clone? > Leaving it open, is the possibility of implementing a true clone api? > Thoughts? Thank you for mentioning this. 1- I do not know where to look for MacOS' function definitions but I followed the same links you shared. It says copyfile(..., COPYFILE_CLONE_FORCE) means 'Clone the file instead. This is a force flag i.e. if cloning fails, an error is returned....' [1]. It does the cloning but I still do not know whether there is a difference between 'copyfile() function with COPYFILE_CLONE_FORCE flag' and 'clonefile()' function. 2- I read a couple of discussions about copy_file_range() and FICLONE. It seems that the copy_file_range() function is a slightly upgraded version of FICLONE but less available since it is newer. It still does the clone [2]. Also, FICLONE is already used in pg_upgrade and pg_combinebackup. Both of these copyfile(..., COPYFILE_CLONE_FORCE) and copy_file_range() functions do the cloning, so I think using clone terminology is correct. But, using FICLONE instead of copy_file_range() could be better since it is more widely available. [1] https://www.unix.com/man-page/mojave/3/copyfile/ [2] https://elixir.bootlin.com/linux/v5.15-rc5/source/fs/read_write.c#L1495 -- Regards, Nazir Bilal Yavuz Microsoft
pgsql-hackers by date: