From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: =?utf-8?B?0JLQsNGB0LjQu9GM0LXQsiDQlNC80LjRgtGA0LjQuQ==?=
 <d.vasilyev@postgrespro.ru>, pgsql-hackers@postgresql.org
Subject: Re: Performance degradation in commit ac1d794
In-reply-to: <20151225211326.z4umuafvv27nczya@alap3.anarazel.de>
References: 
 <CAB-SwXZh44_2ybvS5Z67p_CDz=XFn4hNAD=CnMEF+QqkXwFrGg@mail.gmail.com>
 <EA5F5A26-2E66-4CAB-B3EC-EAD65501B74B@anarazel.de>
 <CAB-SwXZ+6==ZmGvME9vKtUExaQuYYf6oRUNBjkg5SYqv267dUQ@mail.gmail.com>
 <9F7A592C-323B-40CF-AEB6-20D28EAEFFDD@anarazel.de>
 <CAB-SwXb1p6W-_Qrd=h=c47Tv1DuWJwLYNWyq8j9g2yRp4ye-BQ@mail.gmail.com>
 <19322.1451067023@sss.pgh.pa.us>
 <CEAB3A3D-FD33-4AB9-BDD3-FC0E20776245@anarazel.de>
 <19834.1451068135@sss.pgh.pa.us>
 <20151225211326.z4umuafvv27nczya@alap3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
 message dated "Fri, 25 Dec 2015 22:13:26 +0100"
Date: Fri, 25 Dec 2015 16:29:53 -0500
Message-ID: <24833.1451078993@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers