From: Tom Lane <tgl@sss.pgh.pa.us>
To: James Mansion <james@mansionfamily.plus.com>
Cc: Joel Stevenson <joelstevenson@mac.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: LISTEN / NOTIFY performance in 8.3
Date: Tue, 26 Feb 2008 18:33:50 -0500
Message-ID: <9940.1204068830@sss.pgh.pa.us> (raw)
In-Reply-To: <47C48F9E.7000505@mansionfamily.plus.com>
References: <p06240804c3e61871f289@[10.0.1.253]>
<5576.1203795335@sss.pgh.pa.us>
<p06240806c3e67e31cbd0@[10.0.1.253]>
<6730.1203829093@sss.pgh.pa.us>
<p06240812c3e9ea5ea7f8@[10.0.1.253]>
<5080.1204047806@sss.pgh.pa.us>
<47C48F9E.7000505@mansionfamily.plus.com>
James Mansion <james@mansionfamily.plus.com> writes:
> I certainly hadn't expected that to be the implementation technique -
> isn't it smply that we need
> a sngle flag per worker process and can set/test-and-clear with atomic
> operations and then a
> signal to wake them up?
Hardly --- how's that going to pass a notify name? Also, a lot of
people want some payload data in a notify, not just a condition name;
any reimplementation that doesn't address that desire probably won't
get accepted.
There's lots of threads in the -hackers archives about reimplementing
listen/notify in a saner fashion. Personally I lean towards using
something much like the sinval queue.
regards, tom lane
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-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, james@mansionfamily.plus.com, joelstevenson@mac.com
Subject: Re: LISTEN / NOTIFY performance in 8.3
In-Reply-To: <9940.1204068830@sss.pgh.pa.us>
* 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