Skip site navigation (1) Skip section navigation (2)

Re: LISTEN/NOTIFY enhancement: Portable signal handling?

From: Sean Chittenden <sean(at)chittenden(dot)org>
To: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
Cc: "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>,"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: LISTEN/NOTIFY enhancement: Portable signal handling?
Date: 2004-12-27 19:07:23
Message-ID: 8A7EF364-583A-11D9-A9FF-000A95C705DC@chittenden.org (view raw or flat)
Thread:
Lists: pgsql-hackers
>> NOTIFY 'relname' a_expr;
> This would be great to have...at least I think this is what you are
> driving at: (adding a noiseword for readability)
>
> LISTEN system_messages;
> NOTIFY system_messages MESSAGE logoff;
> NOTIFY request_unlock  MESSAGE 12345; <-- for use with user locks!

Hrm... the userlock module may work for what I'm after, but the module 
is GPL'ed, which is something I don't want to rely on.  I wanted to 
have a backend process essentially act as a long running client that 
would act on notify messages to dispatch work.  I was hoping to 
accomplish something like, "LISTEN REGISTER event_name; LISTEN * BLOCK 
WITH TIMEOUT = 30;" which would only listen to events that you've 
registered to listen to, but would only deliver messages when you 
explicitly were going to block waiting for message delivery (ie, LISTEN 
BLOCK).  I'll settle for getting just message passing via NOTIFY/LISTEN 
to work and will revisit extending things further once I have this bit 
done.  -sc

-- 
Sean Chittenden


In response to

pgsql-hackers by date

Next:From: Sean ChittendenDate: 2004-12-27 19:09:37
Subject: Re: LISTEN/NOTIFY enhancement: Portable signal handling?
Previous:From: Merlin MoncureDate: 2004-12-27 18:24:29
Subject: Re: LISTEN/NOTIFY enhancement: Portable signal handling?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group