From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Michael Paquier <michael(at)paquier(dot)xyz> |
Subject: | Re: file cloning in pg_upgrade and CREATE DATABASE |
Date: | 2018-06-06 15:58:14 |
Message-ID: | 0241eae2-2f31-3667-200d-ae0e2293f692@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I have made a major revision of this patch.
I have removed all the changes to CREATE DATABASE. That was too
contentious and we got lost in unrelated details there. The real
benefit is for pg_upgrade.
Another point was that for pg_upgrade use a user would like to know
beforehand whether reflinking would be used, which was not possible with
the copy_file_range() API. So here I have switched to using the ioctl()
call directly.
So the new interface is that pg_upgrade has a new option
--reflink={always,auto,never}. (This option name is adapted from GNU
cp.) From the documentation:
<para>
The setting <literal>always</literal> requires the use of relinks. If
they are not supported, the <application>pg_upgrade</application> run
will abort. Use this in production to limit the upgrade run time.
The setting <literal>auto</literal> uses reflinks when available,
otherwise it falls back to a normal copy. This is the default. The
setting <literal>never</literal> prevents use of reflinks and always
uses a normal copy. This can be useful to ensure that the upgraded
cluster has its disk space fully allocated and not shared with the old
cluster.
</para>
Also, pg_upgrade --check will check whether the selected option would work.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment | Content-Type | Size |
---|---|---|
v3-0001-pg_upgrade-Allow-use-of-file-cloning.patch | text/plain | 13.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2018-06-06 16:08:40 | Re: Explain buffers wrong counter with parallel plans |
Previous Message | Jonathan S. Katz | 2018-06-06 15:57:31 | Re: commitfest 2018-07 |