[fauigerzigerk]

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.

[Erwin]

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.

[fauigerzigerk]

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

[nunwuo]

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

[fauigerzigerk]

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.