Tim Landscheidt wrote: > The main disadvantage in using a listener is that it is your > responsibility to make sure that the listener is listening > 24/7 - from before the database accepts other connections, > through network failures, bugs, etc. - otherwise notifica- > tions will be lost. Therefore I find it much more reliable > (and easier to program) to copy the relevant data to a table > "mailqueue" (or whatever) and then process that queue every > other minute.
You just have to make sure the listener scans the table for possible events that were missed. Think of notifications as signals to wake up and check for possible work, not data carriers. The mailqueue table should still be there for the data. The only difference between your approach and mine is that you poll every minute instead of sleeping until getting a notification. If your system is going to be receiving notifications fairly frequently, it is probably better to stay with polling. (This is what Skype's replication system does, and Hannu Krossing says "what, are you going to optimize for the time when the server is idle?") -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
