Re: CREATE DATABASE with filesystem cloning - Mailing list pgsql-hackers

From Robert Haas
Subject Re: CREATE DATABASE with filesystem cloning
Date
Msg-id CA+TgmoaEzYABy_xPMQ3d6nkc1T_9byiWXoLYWEFcvQkqh7VhJw@mail.gmail.com
Whole thread Raw
In response to Re: CREATE DATABASE with filesystem cloning  (Nazir Bilal Yavuz <byavuz81@gmail.com>)
Responses Re: CREATE DATABASE with filesystem cloning
List pgsql-hackers
On Tue, May 7, 2024 at 8:00 AM Nazir Bilal Yavuz <byavuz81@gmail.com> wrote:
> We had an off-list talk with Thomas and we thought making this option
> GUC instead of SQL command level could solve this problem.
>
> I am posting a new rebased version of the patch with some important changes:
>
> * 'createdb_file_copy_method' GUC is created. Possible values are
> 'copy' and 'clone'. Copy is the default option. Clone option can be
> chosen if the system supports it, otherwise it gives error at the
> startup.

This seems like a smart idea, because the type of file copying that we
do during redo need not be the same as what was done when the
operation was originally performed.

I'm not so sure about the GUC name. On the one hand, it feels like
createdb should be spelled out as create_database, but on the other
hand, the GUC name is quite long already. Then again, why would we
make this specific to CREATE DATABASE in the first place? Would we
also want alter_tablespace_file_copy_method and
basic_archive.file_copy_method?

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: SQL:2011 application time
Next
From: Jacob Champion
Date:
Subject: Re: [PATCH] json_lex_string: don't overread on bad UTF8