From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Craig Ringer <craig(at)2ndquadrant(dot)com>, hubert depesz lubaczewski <depesz(at)depesz(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: proposal: contrib module - generic command scheduler |
Date: | 2015-05-14 17:12:49 |
Message-ID: | 5554D791.4060908@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 5/14/15 1:36 AM, Pavel Stehule wrote:
> I don't think we want to log statements, but we should be able to
> log when a job has run and whether it succeeded or not. (log in a
> table, not just a logfile).
>
> This isn't something that can be done at higher layers either; only
> the scheduler will know if the job failed to even start, or whether
> it tried to run the job.
>
>
> I don't agree - generic scheduler can run your procedure, and there you
> can log start, you can run other commands and you can log result (now
> there is no problem to catch any production nonfatal exception).
And what happens when the job fails to even start? You get no logging.
> Personally I afraid about responsibility to maintain this log table -
> when and by who it should be cleaned, who can see results, ... This is
> job for top end scheduler.
Only if the top-end scheduler has callbacks for everytime the bottom-end
scheduler tries to start a job. Otherwise, the top has no clue what the
bottom has actually attempted.
To be clear, I don't think these need to be done in a first pass. I am
concerned about not painting ourselves into a corner though.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2015-05-14 17:18:11 | Re: Final Patch for GROUPING SETS |
Previous Message | Stephen Frost | 2015-05-14 17:11:02 | Re: pgsql: Add pg_audit, an auditing extension |