| 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-10-02 23:32:48 |
| Message-ID: | 20181002233248.GA2609@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Oct 02, 2018 at 02:31:35PM +0200, Peter Eisentraut wrote:
> I can see the argument for that. But I don't understand where the
> automatic mode fits into this. I would like to keep all three modes
> from my patch: copy, clone-if-possible, clone-or-fail, unless you want
> to argue against that.
I'd like to argue against that :)
There could be an argument for having an automatic more within this
scheme, still I am not really a fan of this. When somebody integrates
pg_upgrade within an upgrade framework, they would likely test if
cloning actually works, bumping immediately on a failure, no? I'd like
to think that copy should be the default, cloning being available as an
option. Cloning is not supported on many filesystems anyway..
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2018-10-03 00:32:11 | Re: SSL tests failing with "ee key too small" error on Debian SID |
| Previous Message | Thomas Munro | 2018-10-02 23:31:17 | Re: speeding up planning with partitions |