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
|
Список | 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 по дате отправления: