Re: Performance degradation in commit ac1d794
От | Tom Lane |
---|---|
Тема | Re: Performance degradation in commit ac1d794 |
Дата | |
Msg-id | 24833.1451078993@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Performance degradation in commit ac1d794 (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Performance degradation in commit ac1d794
|
Список | pgsql-hackers |
Andres Freund <andres@anarazel.de> writes: > There's a couple solutions I can think of to that problem: > 1) Use epoll()/kqueue, or other similar interfaces that don't require > re-registering fds at every invocation. My guess is that that'd be > desirable for performance anyway. Portability, on the other hand, would be problematic. > 2) Create a pair of fds between postmaster/backend for each > backend. While obviously increasing the the number of FDs noticeably, > it's interesting for other features as well: If we ever want to do FD > passing from postmaster to existing backends, we're going to need > that anyway. Maybe; it'd provide another limit on how many backends we could run. > 3) Replace the postmaster_alive_fds socketpair by some other signalling > mechanism. E.g. sending a procsignal to each backend, which sets the > latch and a special flag in the latch structure. And what would send the signal? The entire point here is to notice the situation where the postmaster has crashed. It can *not* depend on the postmaster taking some action. regards, tom lane
В списке pgsql-hackers по дате отправления: