Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints
От | Robert Haas |
---|---|
Тема | Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints |
Дата | |
Msg-id | CA+TgmoYS-sTxz9q_SfvK8d31wFqKSvG2F1nMT2oq60hnYvbbbg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints (Dilip Kumar <dilipbalaut@gmail.com>) |
Ответы |
Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints
|
Список | pgsql-hackers |
On Fri, Mar 11, 2022 at 5:21 AM Dilip Kumar <dilipbalaut@gmail.com> wrote: > Changes, 1) it take Robert's patch as first refactoring patch 2) > Rebase other new relmapper apis on top of that in 0002 3) Some code > refactoring in main patch 0005 and also one problem fix, earlier in > wal log method I have removed ForceSyncCommit(), but IMHO that is > equally valid whether we use file_copy or wal_log because in both > cases we are creating the disk files. 4) Support strategy in createdb > tool and add test case as part of 0006. I don't think you've adequately considered temporary relations here. It seems to be that ReadBufferWithoutRelcache() could not be safe on a temprel, because we'd need a BackendId to access the underlying storage. So I think that ReadBufferWithoutRelcache can only accept unlogged or permanent, and maybe the argument ought to be a Boolean instead of a relpersistence value. I thought that this problem might be only cosmetic, but I checked the code that actually does the copy, and there's no filter there on relpersistence either. And I think there should be. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: