Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 6419547701E for ; Fri, 24 Jan 2003 10:37:45 -0500 (EST) Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by postgresql.org (Postfix) with ESMTP id 7A5F2476A0E for ; Fri, 24 Jan 2003 10:32:23 -0500 (EST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.12.6/8.12.6) with ESMTP id h0OFWG5u013297; Fri, 24 Jan 2003 10:32:16 -0500 (EST) To: Achilleus Mantzios Cc: David Durst , pgsql-sql@postgresql.org Subject: Re: Scheduling Events? In-reply-to: References: Comments: In-reply-to Achilleus Mantzios message dated "Fri, 24 Jan 2003 11:52:46 -0200" Date: Fri, 24 Jan 2003 10:32:16 -0500 Message-ID: <13296.1043422336@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by AMaViS new-20020517 X-Archive-Number: 200301/397 X-Sequence-Number: 11262 Achilleus Mantzios writes: > On Fri, 24 Jan 2003, David Durst wrote: >> Here is the basic problem w/ using CRON in an accounting situation. >> >> I can't be sure that cron will always be up when the DB is up, >> so lets say crond goes down for some random reason (User, System error, >> Etc..) > I you cannot depend on your system to run crond > then you should not depend on it to run postgresql either. Indeed. Cron is one of the oldest and most basic Unix daemons. I find it really, really, really hard to believe that any substitute code that anyone might come up with is going to be more reliable than cron. If it makes you feel better, you could institute some cross-checking. For example, have the cron-launched task update a timestamp in some database table whenever it finishes. Then make your user applications check that timestamp when they start up (or every so often) and complain if it's not within the range (now - expected cron frequency, now). That doesn't fix the problem, but at least makes some humans aware of it. regards, tom lane