Re: elegant and effective way for running jobs inside a database

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: elegant and effective way for running jobs inside a database
Дата
Msg-id CAFj8pRAsFMqqShS=zvipxm7QsEsKCzMWgB1YrP1LUPAKt=cXFw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: elegant and effective way for running jobs inside a database  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы Re: elegant and effective way for running jobs inside a database
Список pgsql-hackers
Hello

2012/3/5 Alvaro Herrera <alvherre@commandprompt.com>:
>
> Excerpts from Artur Litwinowicz's message of lun mar 05 16:18:56 -0300 2012:
>> Dear Developers,
>>    I am looking for elegant and effective way for running jobs inside a
>> database or cluster - for now I can not find that solution.
>
> Yeah, it'd be good to have something.  Many people say it's not
> necessary, and probably some hackers would oppose it; but mainly I think
> we just haven't agreed (or even discussed) what the design of such a
> scheduler would look like.  For example, do we want it to be able to
> just connect and run queries and stuff, or do we want something more
> elaborate able to start programs such as running pg_dump?  What if the
> program crashes -- should it cause the server to restart?  And so on.
> It's not a trivial problem.
>

I agree - it is not simple

* workflow support
* dependency support

a general ACID scheduler can be nice (in pg) but it is not really
simple. There was some proposal about using autovacuum demon like
scheduler.

Pavel

> --
> Álvaro Herrera <alvherre@commandprompt.com>
> The PostgreSQL Company - Command Prompt, Inc.
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers


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

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: RFC: Making TRUNCATE more "MVCC-safe"
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Our regex vs. POSIX on "longest match"