Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints
От | Robert Haas |
---|---|
Тема | Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints |
Дата | |
Msg-id | CA+TgmobS0wPbqZQHw3KXLXmOmAdmjhEcG14UBE4vErdETPWW8A@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 Sun, Mar 20, 2022 at 1:34 AM Dilip Kumar <dilipbalaut@gmail.com> wrote: > I thought that way because IIUC, when we are locking the database > tuple we are ensuring that we are calling > ReceiveSharedInvalidMessages() right? And IIUC > ReceiveSharedInvalidMessages(), is designed such a way that it will > consume all the outstanding messages and that's the reason it loops > multiple times if it identifies that the queue is full. And if my > assumption here is correct then I think it is also correct that now we > only need to worry about anyone generating new invalidations and that > is not possible in this case. Well, I don't see how that chain of logic addresses my concern about sinval reset. Mind you, I'm not sure there's an actual problem here, because I tried testing the patch with debug_discard_caches=1 and nothing failed. But I still don't understand WHY nothing failed. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: