Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 1A07763405D for ; Thu, 13 Aug 2009 19:36:37 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 38729-03 for ; Thu, 13 Aug 2009 22:36:20 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from lists.commandprompt.com (host-159.commandprompt.net [207.173.203.159]) by mail.postgresql.org (Postfix) with ESMTP id 5831A63356E for ; Thu, 13 Aug 2009 19:36:26 -0300 (ADT) Received: from perhan.alvh.no-ip.org ([201.220.118.158]) (authenticated bits=0) by lists.commandprompt.com (8.13.8/8.13.8) with ESMTP id n7DMaOBt031447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Aug 2009 15:36:27 -0700 Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id BB6DBD41A4; Thu, 13 Aug 2009 18:36:00 -0400 (CLT) Date: Thu, 13 Aug 2009 18:36:00 -0400 From: Alvaro Herrera To: Tim Landscheidt Cc: pgsql-sql@postgresql.org Subject: Re: mail alert Message-ID: <20090813223600.GW5909@alvh.no-ip.org> References: <20090813215420.GU5909@alvh.no-ip.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (lists.commandprompt.com [207.173.203.159]); Thu, 13 Aug 2009 15:36:27 -0700 (PDT) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.911 tagged_above=-10 required=5 tests=AWL=0.688, BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 200908/72 X-Sequence-Number: 32981 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