Re: proposal: contrib module - generic command scheduler

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: proposal: contrib module - generic command scheduler
Дата
Msg-id 5554D791.4060908@BlueTreble.com
обсуждение исходный текст
Ответ на Re: proposal: contrib module - generic command scheduler  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: proposal: contrib module - generic command scheduler  (Pavel Stehule <pavel.stehule@gmail.com>)
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Final Patch for GROUPING SETS