From: Andres Freund <andres@anarazel.de>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Васильев Дмитрий <d.vasilyev@postgrespro.ru>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: Performance degradation in commit ac1d794
Date: Thu, 14 Jan 2016 18:55:51 +0100
Message-ID: <20160114175551.GM10941@awork2.anarazel.de> (raw)
In-Reply-To: <20160114171421.GK10941@awork2.anarazel.de>
References: <20151225211326.z4umuafvv27nczya@alap3.anarazel.de>
<24833.1451078993@sss.pgh.pa.us>
<20151226112248.uv3qxmroe4va7wke@alap3.anarazel.de>
<20160114143931.GG10941@awork2.anarazel.de>
<CA+Tgmoaay7n0HbqH4BS+XhdOOYhvYJ7DqZGrMXvduZM8UUXedQ@mail.gmail.com>
<20160114155617.GI10941@awork2.anarazel.de>
<CA+TgmoZ_2EgBCXinHsJn=v8bfg3Y3uXpG1xHiQ8g7yRJzwt3Yg@mail.gmail.com>
<20160114170604.GJ10941@awork2.anarazel.de>
<CA+TgmoanS+7wpYZeX1C5Vp1XL56XK7f3mx1T+94QDN0_a+y3Jw@mail.gmail.com>
<20160114171421.GK10941@awork2.anarazel.de>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On 2016-01-14 18:14:21 +0100, Andres Freund wrote:
> On 2016-01-14 12:07:23 -0500, Robert Haas wrote:
> > > Do we want to provide a backward compatible API for all this? I'm fine
> > > either way.
> >
> > How would that work?
>
> I'm thinking of something like;
>
> int WaitOnLatchSet(LatchEventSet *set, int wakeEvents, long timeout);
>
> int
> WaitLatchOrSocket(volatile Latch *latch, int wakeEvents, pgsocket sock,long timeout)
> {
> LatchEventSet set;
>
> LatchEventSetInit(&set, latch);
>
> if (sock != PGINVALID_SOCKET)
> LatchEventSetAddSock(&set, sock);
>
> return WaitOnLatchSet(set, wakeEvents, timeout);
> }
>
> I think we'll need to continue having wakeEvents and timeout parameters
> for WaitOnLatchSet, we quite frequently want to wait socket
> readability/writability, not wait on the socket, or have/not have
> timeouts.
Hm. If we really want to support multiple sockets at some point the
above WaitOnLatchSet signature isn't going to fly, because it won't
support figuring out which fd the event this triggered on.
So it seems we'd need to return something like
struct LatchEvent
{
enum LatchEventType {WL_LATCH_EVENT;WL_TIMEOUT;WL_SOCKET_EVENT; WL_POSTMASTER_EVENT;...} event_type;
int mask;
pgsocket event_sock;
};
that'd also allow to extend this to return multiple events if we want
that at some point. Alternatively we could add a pgsocket* argument, but
that doesn't really seem much better.
Not super happy about the above proposal.
Andres
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: andres@anarazel.de, robertmhaas@gmail.com, tgl@sss.pgh.pa.us, d.vasilyev@postgrespro.ru
Subject: Re: Performance degradation in commit ac1d794
In-Reply-To: <20160114175551.GM10941@awork2.anarazel.de>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox