Re: Two patches to speed up pg_rewind.

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?

In response to

Responses

Browse pgsql-hackers by date

  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