From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Bruce Momjian <bruce(at)momjian(dot)us> |
Subject: | Re: file cloning in pg_upgrade and CREATE DATABASE |
Date: | 2018-07-17 06:58:34 |
Message-ID: | 20180717065833.GG3388@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jun 06, 2018 at 11:58:14AM -0400, Peter Eisentraut wrote:
> <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>
Hm... I am wondering if we actually want the "auto" mode where we make
the option smarter automatically. I am afraid of users trying to use it
and being surprised that there is no gain while they expected some. I
would rather switch that to an on/off switch, which defaults to "off",
or simply what is available now. huge_pages=try was a bad idea as the
result is not deterministic, so I would not have more of that...
Putting CloneFile and check_reflink in a location that other frontend
binaries could use would be nice, like pg_rewind.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-07-17 07:10:05 | Re: Another usability issue with our TAP tests |
Previous Message | Michael Paquier | 2018-07-17 06:46:32 | Re: missing toast table for pg_policy |