Subject: Re: file cloning in pg_upgrade and CREATE DATABASE
To: Michael Paquier <michael@paquier.xyz>
References: <bc9ca382-b98d-0446-f699-8c5de2307ca7@2ndquadrant.com>
 <20180319070636.GA4633@paquier.xyz> <20180319071415.GB4633@paquier.xyz>
 <20180320025849.GB4963@paquier.xyz>
 <678999c6-0967-d22a-e7d1-2a3aff83a77b@2ndquadrant.com>
 <20180322023831.GG2490@paquier.xyz>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Organization: 2ndQuadrant
Message-ID: <9380bebc-3c16-42f0-d0e1-da7c235f8a58@2ndquadrant.com>
Date: Sun, 25 Mar 2018 21:33:38 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0)
 Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <20180322023831.GG2490@paquier.xyz>
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 3/21/18 22:38, Michael Paquier wrote:
> At least on Linux it is possible to rely on sync_file_range which is
> called via pg_flush_data, so it seems to me that we ought to roughly
> keep the loop working on FLUSH_DISTANCE, and replace the calls of
> read/write by copy_file_range.  copyfile is only able to do a complete
> file copy, so we would also lose this property as well on Linux.

I have shown earlier in the thread that copy_file_range in one go is
still better than doing it in pieces.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services