Re: Excessive PostmasterIsAlive calls slow down WAL redo
От | Thomas Munro |
---|---|
Тема | Re: Excessive PostmasterIsAlive calls slow down WAL redo |
Дата | |
Msg-id | CAEepm=0vT4ekDnN1p1eSqgQOc0q5oaoGoaF0QuZf_BRsEtaQpg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Excessive PostmasterIsAlive calls slow down WAL redo (Thomas Munro <thomas.munro@enterprisedb.com>) |
Ответы |
Re: Excessive PostmasterIsAlive calls slow down WAL redo
|
Список | pgsql-hackers |
On Wed, Apr 25, 2018 at 6:23 PM, Thomas Munro <thomas.munro@enterprisedb.com> wrote: > On Tue, Apr 24, 2018 at 7:37 PM, Michael Paquier <michael@paquier.xyz> wrote: >> Thomas, trying to understand here... Why this place for the signal >> initialization? Wouldn't InitPostmasterChild() be a more logical place >> as we'd want to have this logic caught by all other processes? > > Yeah, you're right. Here's one like that. Amazingly, due to the way the project schedules fell and thanks to the help of a couple of very supportive FreeBSD committers and reviewers, the new PROC_PDEATHSIG_CTL kernel facility[1] landed in a production release today, beating the Commitfest by several days. My question is whether this patch set is enough, or people (Andres?) want to go further and actually kill the postmaster death pipe completely. My kqueue patch would almost completely kill it on BSDs as it happens, but for Linux there are a number of races and complications to plug to do that IIUC. I don't immediately see what there is to gain by doing that work (assuming we reuse WaitEventSet objects in enough places), and we'll always need to maintain the pipe code for other OSes anyway. So I'm -0.5 on doing that, even though the technical puzzle is appealing... [1] https://www.freebsd.org/cgi/man.cgi?query=procctl&apropos=0&sektion=2&manpath=FreeBSD+11.2-RELEASE&arch=default&format=html -- Thomas Munro http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: