3 ms·
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 look
by fauigerzigerk 12y ago
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.
- nunwuo 12y agoHuh? The entire point of listen/notify is exactly that you don't have to poll.
- fauigerzigerk 12y agoAnd 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 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.
- Erwin 12y agoYour 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-notifications 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 12y agoYou 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 http://www.postgresql.org/docs/9.4/static/libpq-notify.html