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

From Peter Eisentraut
Subject Re: file cloning in pg_upgrade and CREATE DATABASE
Date
Msg-id e15a6c65-267e-6328-734b-620fdf6772c2@2ndquadrant.com
Whole thread Raw
In response to Re: file cloning in pg_upgrade and CREATE DATABASE  (Michael Paquier <michael@paquier.xyz>)
Responses Re: file cloning in pg_upgrade and CREATE DATABASE  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
On 17.07.18 08:58, Michael Paquier wrote:
> 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...

Why do you think that was a bad idea?  Doing the best possible job by
default without requiring explicit configuration in each case seems like
an attractive feature.

> Putting CloneFile and check_reflink in a location that other frontend
> binaries could use would be nice, like pg_rewind.

This could be done in subsequent patches, but the previous iteration of
this patch for CREATE DATABASE integration already showed that each of
those cases needs separate consideration.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: [HACKERS] Restricting maximum keep segments by repslots
Next
From: Ashutosh Bapat
Date:
Subject: Re: foreign key to foreign table