Re: LISTEN/NOTIFY enhancement: Portable signal handling?

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.
>
> 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?

You can make cooperative blocking locks using some slick client side
code and the swiss army knife userlock module. Since user locks pierce
transaction encapsulation they can be used for these types of things.

select user_write_lock(some number);
if return = 1
notify some message
else
wait a and try again, etc.
end if

// release lock, etc.

> 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!

Etc.

Another cute tidbit about the listen/notify interface is that it can be
abused to create server side storage that is cleaned up by the server
when a backend drops. I was using this to crate a crude pessimistic
locking system before I discovered the userlock module. Note that this
is not a scalable or robust approach however.

listen 12345; <--acquired a lock on '12345'
select listenerpid from pg_listener where relname = '12345'

Merlin