LISTEN name [BLOCK] [WITH] [TIMEOUT [=] ''::INTERVAL]; NOTIFY name a_expr;
But am having something of a think-o when it comes to the semantics of the BLOCK keyword for the LISTEN command. Let me first explain my goals for this exercise:
* Allow passing of a data type in a NOTIFY. Something like:
NOTIFY 'relname' a_expr;
Should be able to pass a text, INET, etc... shouldn't matter... not sure if this is possible though given that OIDs don't travel with data types... I may have to settle for a TEXT arg, which is acceptable.
* 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 while blocking.
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 BLOCK'ing semantics or implementation. There are two ways that I can do this, IMHO, but I'm out to solicit alternatives as I'm still getting a handle on what the best interfaces/APIs are internally to get something done.
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.
Option 2) block on an exclusive lock. Check to see if relname has been registered. If it has, block on the existing exclusive lock (can I block on a lock for a given number of sec/ms?). If it hasn't, create an exclusive lock, but give the lock away (to the parent postmaster, a lockmgr proc, etc) so that a notify can remove the remove and unlock the exclusive lock so that all of the blocking children wake up.
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. Does anyone think there would be any conflicts with the use of the existing alarm code from storage/lmgr/proc.c for the LISTEN/NOTIFY interface? It looks like SIGALRM has a reserved purpose. I haven't found any global alarm handling interface that can be used to assign different meanings when an SIGALRM is received. Any other thoughts on the best way to proceed?
-sc
-- Sean Chittenden
---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
