From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Paul Guo <guopa(at)vmware(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Two patches to speed up pg_rewind. |
Date: | 2021-06-02 06:20:30 |
Message-ID: | CA+hUKGKG2hNxmOnmCZ9Bx==-dYZDLiG-vWEBNbshMtRUSo+7KA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jun 2, 2021 at 5:20 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> Note: FreeBSD 13~ has support for copy_file_range(), nice.. Adding
> Thomas in CC in case I am missing something.
Yeah, so at least in theory Linux and FreeBSD can now both do tricks
like pushing copies down to network filesystems, COW file systems, and
(I believe not actually done by anyone yet, could be wrong) SCSI and
NVMe devices (they have commands like XCOPY that can copy block ranges
directly). I read a few things about all that, and I had a trivial
patch to try to use it in the places in the backend where we copy
files (like cloning a database with CREATE DATABASE and moving files
with ALTER TABLE SET TABLESPACE), but I hadn't got as far as actually
trying it on any interesting filesystems or figuring out any really
good uses for it. FWIW, here it is:
https://github.com/postgres/postgres/compare/master...macdice:copy_file_range
The main thing I noticed was that Linux < 5.3 can fail with EXDEV if
you cross a filesystem boundary, is that something we need to worry
abou there?
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2021-06-02 06:22:52 | Re: Decoding speculative insert with toast leaks memory |
Previous Message | Peter Smith | 2021-06-02 06:13:06 | Re: Refactor "mutually exclusive options" error reporting code in parse_subscription_options |