Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion Who is LISTENing?

Received: by 10.180.107.167 with SMTP id hd7mr3638029wib.0.1350394161045;
        Tue, 16 Oct 2012 06:29:21 -0700 (PDT)
Path: q10ni65142469wif.0!nntp.google.com!goblin2!goblin1!goblin.stu.neva.ru!news.mixmin.net!feeder.erje.net!news.hub.org!.POSTED!postgresql.org!pgsql-general-owner+M191469=pgsql+2Dgeneral=news.postgresql.org
From: chris.trav...@gmail.com (Chris Travers)
Newsgroups: pgsql.general
Subject: Re: Who is LISTENing?
Date: Tue, 16 Oct 2012 06:29:09 -0700
Organization: Hub.Org Networking Services
Lines: 121
Sender: n...@news.hub.org
Message-ID: <CAKt_ZftQCqLypXYPPrN-4+vQZM47jKh+3m5rTWgqqbh2VVWxiQ@mail.gmail.com>
References: <20121015161138.GA17738@eldergods.com>
	<k5jjbf$jk5$1@reversiblemaps.ath.cx>
NNTP-Posting-Host: news.hub.org
Mime-Version: 1.0
X-Trace: news.hub.org 1350394160 23862 200.46.204.72 (16 Oct 2012 13:29:20 GMT)
X-Complaints-To: usenet@news.hub.org
NNTP-Posting-Date: Tue, 16 Oct 2012 13:29:20 +0000 (UTC)
X-Received: from malur.postgresql.org (malur.postgresql.org [217.196.149.56])
	by news.hub.org (8.14.5/8.14.5) with ESMTP id q9GDTIgq023847
	for <pgsql-gene...@news.postgresql.org>; Tue, 16 Oct 2012 10:29:19 -0300 (ADT)
	(envelope-from pgsql-general-owner+M191469=pgsql+2Dgeneral=news.postgresql....@postgresql.org)
X-Received: from localhost ([127.0.0.1] helo=postgresql.org)
	by malur.postgresql.org with smtp (Exim 4.72)
	(envelope-from <pgsql-general-owner+M191469=pgsql+2Dgeneral=news.postgresql....@postgresql.org>)
	id 1TO7Cw-0002F1-5y
	for pgsql-gene...@news.postgresql.org; Tue, 16 Oct 2012 13:29:18 +0000
X-Received: from makus.postgresql.org ([98.129.198.125])
	by malur.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <chris.trav...@gmail.com>)
	id 1TO7Cu-0002EZ-H1
	for pgsql-gene...@postgresql.org; Tue, 16 Oct 2012 13:29:16 +0000
X-Received: from mail-oa0-f46.google.com ([209.85.219.46])
	by makus.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <chris.trav...@gmail.com>)
	id 1TO7Cq-0003nJ-3z
	for pgsql-gene...@postgresql.org; Tue, 16 Oct 2012 13:29:15 +0000
X-Received: by mail-oa0-f46.google.com with SMTP id h16so6156431oag.19
        for <pgsql-gene...@postgresql.org>; Tue, 16 Oct 2012 06:29:11 -0700 (PDT)
X-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        bh=rDsEUPK+GJ91ZJ8838BWi7Sqt9T5mqZEx04kRETDdL4=;
        b=w/jPY5JLHvicrEEu/B0ApjA2m8zieIKZdh0mXSmbbWpdv+7GUVeyanymFzzh2hICyD
         /gTUOaHnxgm3KXbFCFXhUNMVjcsVOAEriX1SoAHggRJZ3Y7TY1jBLc3UlA8JVdJsSwvN
         6uz651T3VrKNxszVbUn8qAGxFeTbFHk/1GKMoF7ice6cCZ5hh7SbkqNmyeUMukv0iYZo
         zyEXMYPqWlDZUY+v52i8TvEOPvMXl4kNHHseYM4KSRwyAsM6PgK2r4hTJJyLLgCugs6Y
         il2KhVmE8O36Pl2twLAKH9w3PBk3aHliI1CSlQMcytRas6RLDJKq2ktT4CmizMfuO5eO
         Uv4g==
X-Received: by 10.182.64.34 with SMTP id l2mr3759352obs.28.1350394149574; Tue,
 16 Oct 2012 06:29:09 -0700 (PDT)
X-Received: by 10.76.135.34 with HTTP; Tue, 16 Oct 2012 06:29:09 -0700 (PDT)
X-In-Reply-To: <k5jjbf$jk...@reversiblemaps.ath.cx>
X-To: Jasen Betts <ja...@xnet.co.nz>
X-Cc: pgsql-gene...@postgresql.org
X-Pg-Spam-Score: -2.6 (--)
X-List-Archive: <http://archives.postgresql.org/pgsql-general>
X-List-Help: <mailto:majord...@postgresql.org?body=help>
X-List-ID: <pgsql-general.postgresql.org>
X-List-Owner: <mailto:pgsql-general-ow...@postgresql.org>
X-List-Post: <mailto:pgsql-gene...@postgresql.org>
X-List-Subscribe: <mailto:majord...@postgresql.org?body=sub%20pgsql-general>
X-List-Unsubscribe: <mailto:majord...@postgresql.org?body=unsub%20pgsql-general>
X-Mailing-List: pgsql-general
X-Precedence: bulk
Content-Type: multipart/alternative; boundary=14dae93a190997973504cc2d23aa

--14dae93a190997973504cc2d23aa
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Oct 16, 2012 at 5:18 AM, Jasen Betts <ja...@xnet.co.nz> wrote:

> On 2012-10-15, rektide <rekt...@voodoowarez.com> wrote:
> > Hi pgsql-general,
> >
> > I'm interested in writing a supervisory process that can insure worker
> processes are
> > running/spawn new ones if not. These workers will mainly be responsible
> for LISTENing to
> > the db, which is emitting triggered_change_notification s.
> >
> > Is there any means to check a NOTIFY queue to see who or if anyone is
> LISTEN ing on it?
> >
>
> Notifies are not reliable, what I mean is they are "best effort"
> this is unlike the other things postgres does, there's no guarantee
> that you'll get the message, for example the network might go down at
> the same time as the notifiy is emitted, if that happenss a listening
> client would miss the notify message and by the time it reconnects the
> message is gone.
>
> If you need reliable mesaging use a mesage queue in a table:
> Emit a notify when you insert into the queue and the listeners can check
> the queue when they connect, and again after each notify.
>
> OTOH, if best effort is good enough,  the table pg_stat_activity will give
> you the username of each connected client. perhaps ypu can infer from that
> who was probably listening when you last checked...
>

One of the goals of pg_message_queue was to create a simple message queue
system with listen/notify support (which is missing in pgq btw).  It is
designed to be reasonably reliable but is still relatively feature poor.
 It will probably never be big and professional like pgq, but may be very
helpful in many cases nonetheless.   http://pgxn.org/dist/pg_message_queue/

The basic idea is that it automates some of the basic bailing twine you
might want to create in such a solution.  Future versions will have more
logging, anti-refutation controls, etc.

Note the way we addressed this problem was that listen/notify was optional.
 An application could be run from cron once a day and process queued items,
or it could connect and wait for notifications.

As of 0.1, it supports payload types of text, xml, and bytea.  More types
coming soon in 0.2.

I would be interested in feedback on this, and if anyone wants to
contribute, I certainly will be happy to facilitate.

Best Wishes,
Chris Travers

--14dae93a190997973504cc2d23aa
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Tue, Oct 16, 2012 at 5:18 AM, Jasen B=
etts <span dir=3D"ltr">&lt;<a href=3D"mailto:ja...@xnet.co.nz" target=3D"_b=
lank">ja...@xnet.co.nz</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">
<div class=3D"im">On 2012-10-15, rektide &lt;<a href=3D"mailto:rektide@vood=
oowarez.com">rekt...@voodoowarez.com</a>&gt; wrote:<br>
&gt; Hi pgsql-general,<br>
&gt;<br>
&gt; I&#39;m interested in writing a supervisory process that can insure wo=
rker processes are<br>
&gt; running/spawn new ones if not. These workers will mainly be responsibl=
e for LISTENing to<br>
&gt; the db, which is emitting triggered_change_notification s.<br>
&gt;<br>
&gt; Is there any means to check a NOTIFY queue to see who or if anyone is =
LISTEN ing on it?<br>
&gt;<br>
<br>
</div>Notifies are not reliable, what I mean is they are &quot;best effort&=
quot;<br>
this is unlike the other things postgres does, there&#39;s no guarantee<br>
that you&#39;ll get the message, for example the network might go down at<b=
r>
the same time as the notifiy is emitted, if that happenss a listening<br>
client would miss the notify message and by the time it reconnects the<br>
message is gone.<br>
<br>
If you need reliable mesaging use a mesage queue in a table:<br>
Emit a notify when you insert into the queue and the listeners can check<br=
>
the queue when they connect, and again after each notify.<br>
<br>
OTOH, if best effort is good enough, =A0the table pg_stat_activity will giv=
e<br>
you the username of each connected client. perhaps ypu can infer from that<=
br>
who was probably listening when you last checked...<br></blockquote><div><b=
r></div><div>One of the goals of pg_message_queue was to create a simple me=
ssage queue system with listen/notify support (which is missing in pgq btw)=
. =A0It is designed to be reasonably reliable but is still relatively featu=
re poor. =A0It will probably never be big and professional like pgq, but ma=
y be very helpful in many cases nonetheless. =A0 <a href=3D"http://pgxn.org=
/dist/pg_message_queue/">http://pgxn.org/dist/pg_message_queue/</a></div>
<div><br></div><div>The basic idea is that it automates some of the basic b=
ailing twine you might want to create in such a solution. =A0Future version=
s will have more logging, anti-refutation controls, etc.</div><div><br></di=
v>
<div>Note the way we addressed this problem was that listen/notify was opti=
onal. =A0An application could be run from cron once a day and process queue=
d items, or it could connect and wait for notifications.</div><div><br></di=
v>
<div>As of 0.1, it supports payload types of text, xml, and bytea. =A0More =
types coming soon in 0.2.</div><div><br></div><div>I would be interested in=
 feedback on this, and if anyone wants to contribute, I certainly will be h=
appy to facilitate.</div>
<div><br></div><div>Best Wishes,</div><div>Chris Travers</div></div>

--14dae93a190997973504cc2d23aa--