Re: Performance degradation in commit ac1d794

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Васильев Дмитрий <d(dot)vasilyev(at)postgrespro(dot)ru>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Performance degradation in commit ac1d794
Date: 2015-12-25 21:29:53
Message-ID: 24833.1451078993@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2015-12-25 22:10:43 9.5rc1 brin_summarize_new_values
Previous Message Andres Freund 2015-12-25 21:13:26 Re: Performance degradation in commit ac1d794