From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Artur Litwinowicz <admin(at)ybka(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: elegant and effective way for running jobs inside a database |
Date: | 2012-03-07 08:25:14 |
Message-ID: | CAFj8pRDQYL6uix3XQ7BnFYF2N-oa1MzhAT+HkFsu=FU4kD-V4Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2012/3/7 Simon Riggs <simon(at)2ndquadrant(dot)com>:
> On Tue, Mar 6, 2012 at 3:21 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> But having said that, it's not apparent to me why such a thing would
>> need to live "inside the database" at all. It's very easy to visualize
>> a task scheduler that runs as a client and requires nothing new from the
>> core code. Approaching the problem that way would let the scheduler
>> be an independent project that stands or falls on its own merits.
>
> On Tue, Mar 6, 2012 at 4:36 PM, Alvaro Herrera
> <alvherre(at)commandprompt(dot)com> wrote:
>
>> What such an external scheduler would need from core is support for
>> starting up and shutting down along postmaster (as well as restarts at
>> appropriate times). Postmaster already has the ability to start and
>> shut down many processes depending on several different policies; I
>> think it's mostly a matter of exporting that functionality in a sane way.
>
> Tom's question is exactly on the money, and so is Alvaro's answer.
>
> Many, many people have requested code that "runs in core", but the key
> point is that all they actually want are the core features required to
> build one. The actual projects actively want to live outside of core.
> The "run in core" bit is actually just what Alvaro says, the ability
> to interact gracefully for startup and shutdown.
>
> What I think we need is an API like the LWlock add in requests, so we
> can have a library that requests it is assigned a daemon to run in,
> looking very much like autovacuum launcher, with the guts removed. It
> would then be a matter for the code authors as to whether it was a
> client program that interacts with server, or whether it was a full
> blown daemon like autovacuum.
>
it is true - first step should be short - and maintaining, assign to
jobs and others can be implemented as extension. There is not
necessary SQL api (other than functions).
Regards
Pavel
> We talked about this at last year's Dev meeting. And we got
> sidetracked into "what we really want is stored procedures". Maybe we
> want that, but its a completely separate thing. Please lets not get
> distracted from a very simple thing because of the existence of other
> requirements.
>
> --
> Simon Riggs http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2012-03-07 08:35:44 | Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock) |
Previous Message | Simon Riggs | 2012-03-07 08:15:03 | Re: elegant and effective way for running jobs inside a database |