Hacker News Reader

Comment by fauigerzigerk | Hacker News Reader

One problem I have with using postgres listen/notify as a general purpose message queue is that it requires polling (At least that was the case when I last looked at it). Of course you can use a blocking wrapper around the polling code but it still causes unnecessary roundtrips.

View on HN

Your database connection is just a socket, so you can add that file descriptor to the set of file descriptors you are waiting IO on, if you are using a classic select/poll based system. See an example in the pscyopg2 docs here: http://initd.org/psycopg/docs/advanced.html#asynchronous-not...

Once that FD is active, you call the poll() method and your notify payload becomes available to you.

You are right. It seems that this was an issue with older versions of libpq: "In prior releases of libpq, the only way to ensure timely receipt of NOTIFY messages was to constantly submit commands" http://www.postgresql.org/docs/9.4/static/libpq-notify.html

Huh? The entire point of listen/notify is exactly that you don't have to poll.

And yet in previous versions of libpq polling was the only way to use listen/notify. I'm not sure if it was a limitation of libpq or the server implementation itself: http://www.postgresql.org/docs/9.4/static/libpq-notify.html

It's still not a particularly simple interface as you have to check for notifications after every single SQL command if I understand it correctly.

Reply on news.ycombinator.com