Re: elegant and effective way for running jobs inside a database - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: elegant and effective way for running jobs inside a database
Date
Msg-id CAFj8pRDQYL6uix3XQ7BnFYF2N-oa1MzhAT+HkFsu=FU4kD-V4Q@mail.gmail.com
Whole thread Raw
In response to Re: elegant and effective way for running jobs inside a database  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
2012/3/7 Simon Riggs <simon@2ndquadrant.com>:
> On Tue, Mar 6, 2012 at 3:21 PM, Tom Lane <tgl@sss.pgh.pa.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@commandprompt.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@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: elegant and effective way for running jobs inside a database
Next
From: Simon Riggs
Date:
Subject: Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock)