2015-05-14 19:12 GMT+02:00 Jim Nasby <jim.na...@bluetreble.com>: > 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. >
Is only one case - when job is not started due missing worker. Else where is started topend executor, that can run in protected block. > > 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. > sure. > > 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. I understand Regards Pavel > > -- > Jim Nasby, Data Architect, Blue Treble Consulting > Data in Trouble? Get it in Treble! http://BlueTreble.com >
