Re: file cloning in pg_upgrade and CREATE DATABASE

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: file cloning in pg_upgrade and CREATE DATABASE
Date: 2018-03-20 14:55:04
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

On 3/19/18 22:58, Michael Paquier wrote:
> I have been thinking about this patch over the night, and here is a list
> of bullet points which would be nice to tackle:
> - Remove the current diff in copydir.


> - Extend copy_file so as it is able to use fcopyfile.

fcopyfile() does not support cloning. (This is not documented.)

> - Move the work done in pg_upgrade into a common API which can as well
> be used by pg_rewind as well. One place would be to have a
> frontend-only API in src/common which does the leg work. I would
> recommend working only on file descriptors as well for consistency with
> copy_file_range.

pg_upgrade copies files, whereas pg_rewind needs to copy file ranges.
So I don't think this is going to be a good match.

We could add support for using Linux copy_file_range() in pg_rewind, but
that would work a bit differently. I also don't have a good sense of
how to test the performance of that.

Another thing to think about is that we go through some trouble to
initialize new WAL files so that the disk space is fully allocated. If
we used file cloning calls in pg_rewind, that would potentially
invalidate some of that. At least, we'd have to think through this more

> - Add proper wait events for the backend calls. Those are missing for
> copy_file_range and copyfile.


> - For XLogFileCopy, the problem may be trickier as the tail of a segment
> is filled with zeroes, so dropping it from the first version of the
> patch sounds wiser.

Seems like a possible follow-on project. But see also under pg_rewind

Another oddity is that pg_upgrade uses CopyFile() on Windows, but the
backend does not. The Git log shows that the backend used to use
CopyFile(), but that was then removed when the generic code was added,
but when pg_upgrade was imported, it came with the CopyFile() call.

I suspect the CopyFile() call can be quite a bit faster, so we should
consider adding it back in. Or if not, remove it from pg_upgrade.

Peter Eisentraut
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment Content-Type Size
v2-0001-Use-file-cloning-in-pg_upgrade-and-CREATE-DATABAS.patch text/plain 13.0 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-03-20 14:57:32 Re: [PoC PATCH] Parallel dump to /dev/null
Previous Message Alvaro Herrera 2018-03-20 14:54:50 Re: pgsql: Fix CommandCounterIncrement in partition-related DDL