Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints
| От | Dilip Kumar |
|---|---|
| Тема | Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints |
| Дата | |
| Msg-id | CAFiTN-t9y6Mgx6zD7U1QuzA56gXzo6WbeUFrnzGHmkmXTEFBAA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints
|
| Список | pgsql-hackers |
On Wed, Sep 8, 2021 at 9:54 PM Robert Haas <robertmhaas@gmail.com> wrote:
On Fri, Sep 3, 2021 at 5:54 PM Andres Freund <andres@anarazel.de> wrote:
> > I think we already have such a code in multiple places where we bypass the
> > shared buffers for copying the relation
> > e.g. index_copy_data(), heapam_relation_copy_data().
>
> That's not at all comparable. We hold an exclusive lock on the relation at
> that point, and we don't have a separate implementation of reading tuples from
> the table or something like that.
I don't think there's a way to do this that is perfectly clean, so the
discussion here is really about finding the least unpleasant
alternative. I *really* like the idea of using pg_class to figure out
what relations to copy. As far as I'm concerned, pg_class is the
canonical list of what's in the database, and to the extent that the
filesystem happens to agree, that's good luck. From that perspective,
using the filesystem to figure out what to copy is by definition a
hack.
I agree with you, even though I think that scanning pg_class for identifying the relfilenode looks like a more sensible thing to do than directly scanning the file system, we need to consider one point that, now also in current system (in create database) we are scanning the directory for copying the file so instead of copying them directly we need to logically identify the relfilenode and then copy it block by block, so maybe this approach will not make anyone unhappy because it is not any worse than the current system.
В списке pgsql-hackers по дате отправления: