In case anyone's wondering why I'm replying to an article that's nearly a
year old, it came up in a search while I was looking for the more recent
LISTEN/NOTIFY thread...
In article [EMAIL PROTECTED],
Tom Lane [EMAIL PROTECTED] wrote:
Sean Chittenden [EMAIL PROTECTED] writes:
The async
Howdy. I'm starting some work on our favorite LISTEN/NOTIFY subsystem
in the hopes of more advanced functionality. Right now I'm using a
bastardized (RAISE NOTICE + tailing error logs) + NOTIFY to get what
should just be built in to the LISTEN/NOTIFY interface. Here's the
syntax for the
Basically I want to introduce formal support for turning
PostgreSQL into a message bus. To start with, it won't be a
scalable message bus that can scale to thousands of
concurrent connections (that's something I'd like to do long
term(tm), but I digress). The problem is with the
Sean Chittenden [EMAIL PROTECTED] writes:
* Allow LISTEN to block until a value changes. LISTEN [BLOCK|WAIT]
'relname'
* Allow LISTEN to have a timeout
LISTEN name [BLOCK] [WITH] [TIMEOUT [=] ''::INTERVAL];
* Allow blocking LISTEN queries to update the status of the proc title
Sean Chittenden [EMAIL PROTECTED] writes:
The async interface is nice, but not really useful to me as it requires
polling, instead of unblocking when an event comes through, which would
create a vastly more real time interface that should be easier on the
database.
BTW, this is nonsense;
Sean Chittenden wrote:
Option 1) Use sleep(3) for the given timeout and wake up on some
interruptible a signal (USR2?). This is the simplest solution, but
likely the least portable to win32. Given the new world order of 8.0
and it's portability headaches, it's something I'm aware of.
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
The async interface is nice, but not really useful to me as it
requires
polling, instead of unblocking when an event comes through, which
would
create a vastly more real time interface that should be easier on the
database.
BTW, this is nonsense; the backend sends a message exactly when the
