tag:blogger.com,1999:blog-3346090548501966296.post8640778542778795463..comments2024-03-26T05:03:04.875-07:00Comments on Perspectives on LedgerSMB: Object/Relational Interlude: Messaging in PostgreSQLChris Travershttp://www.blogger.com/profile/06211762965865744803noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-3346090548501966296.post-59172085230198665172012-09-16T19:38:46.041-07:002012-09-16T19:38:46.041-07:00The code has not been updated since we were workin...The code has not been updated since we were working with DBD::Pg 1.x. It's good to see comments like this though which alert users to areas which are out of date.<br /><br />As for the rest of it, that sounds like a better approach. As I say this was intended as sample code and is certainly not production-centric.Chris Travershttps://www.blogger.com/profile/06211762965865744803noreply@blogger.comtag:blogger.com,1999:blog-3346090548501966296.post-61504236956854316392012-09-16T14:08:48.804-07:002012-09-16T14:08:48.804-07:00I've used this in Perl DBD-Pg code in a daemon...I've used this in Perl DBD-Pg code in a daemon using event based code (AnyEvent as the case was, but could have been IO::Async, POE, Gtk2, Reflex, anything that can create filehandle watchers) by setting $dbh->{pg_socket} to non-blocking, calling the LISTEN and adding the socket to the event loop and checking pg_notifies on events on that socket.<br /><br />BTW, current DBD::Pg has a pg_notifies method on the database handle now, no longer need to call func('pg_notifies')<br />Unknownhttps://www.blogger.com/profile/13272926101694279195noreply@blogger.comtag:blogger.com,1999:blog-3346090548501966296.post-90884272399618071082012-09-13T06:53:41.799-07:002012-09-13T06:53:41.799-07:00I actually use LISTEN/NOTIFY to send messages to a...I actually use LISTEN/NOTIFY to send messages to a daemon that handle data archiving and out of band processing, and it works great. But in order to really reduce the work and checks on the daemon, I use the Postgres libs ability to check if there is any action on the TCP connection, as NOTIFY will actually cause an activity on the connection. Then using Ruby's Postgres GEM I do something like:<br />@db_conn.wait_for_notify() do |event, pid, extra|<br /> do_notify_work(event, pid, extra) <br />end<br /><br />SO the daemon is only doing work when there is a notification on the connection, and then it checks if it's actually a NOTIFY and pass control to my execution block. <br /><br />Of course there's some code around it to protect from timeouts, terminations, etc... Guy Naorhttps://www.blogger.com/profile/14981602607414535617noreply@blogger.com