Re: file cloning in pg_upgrade and CREATE DATABASE

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: file cloning in pg_upgrade and CREATE DATABASE
Дата
Msg-id 20180717065833.GG3388@paquier.xyz
обсуждение исходный текст
Ответ на Re: file cloning in pg_upgrade and CREATE DATABASE  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Ответы Re: file cloning in pg_upgrade and CREATE DATABASE  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: missing toast table for pg_policy
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Another usability issue with our TAP tests