Re: LISTEN/NOTIFY enhancement: Portable signal handling?

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

Sounds great :-)

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

There should be no problem doing this on win32. The portability layer
(in backend/port/win32) implements a sleep (pg_usleep, that is) that can
be interrupted by any signal (our win32 signal implementation actually
supports 256 signals, but you'd have to stick to a signal that's
supported on all platforms and also not already in use. And that's going
to be a lot harder unless you can piggyback on something that's already
there).

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

As long as you're working only from the client side, you don't need to
do polling. See the bottom of the page at
http://developer.postgresql.org/docs/postgres/libpq-notify.html. You
just need to pass the socket down to select(). I'm doing this from C and
perl, don't know about other languages.

That said, there are certainly a lot of cases where a blocking call at
the SQL level would also be useful. Just don't kill what we have now :-)

//Magnus