Re: file cloning in pg_upgrade and CREATE DATABASE - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: file cloning in pg_upgrade and CREATE DATABASE
Date
Msg-id 20181002233248.GA2609@paquier.xyz
Whole thread Raw
In response to Re: file cloning in pg_upgrade and CREATE DATABASE  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: file cloning in pg_upgrade and CREATE DATABASE  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List 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

Attachment

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: speeding up planning with partitions
Next
From: Michael Paquier
Date:
Subject: Re: SSL tests failing with "ee key too small" error on Debian SID