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