Robert Haas writes:
> On Sat, Feb 20, 2010 at 4:41 PM, Merlin Moncure wrote:
>> IMNSHO, an 'in core' scheduler would be useful. however, I think
>> before you tackle a scheduler, we need proper stored procedures. Our
>> existing functions don't cut it because you can manage the transaction
>> st
On Mon, Mar 1, 2010 at 4:43 PM, Robert Haas wrote:
> On Sat, Feb 20, 2010 at 4:41 PM, Merlin Moncure wrote:
>> IMNSHO, an 'in core' scheduler would be useful. however, I think
>> before you tackle a scheduler, we need proper stored procedures. Our
>> existing functions don't cut it because you c
2010/3/1 Robert Haas :
> On Sat, Feb 20, 2010 at 4:41 PM, Merlin Moncure wrote:
>> IMNSHO, an 'in core' scheduler would be useful. however, I think
>> before you tackle a scheduler, we need proper stored procedures. Our
>> existing functions don't cut it because you can manage the transaction
>>
On Sat, Feb 20, 2010 at 4:41 PM, Merlin Moncure wrote:
> IMNSHO, an 'in core' scheduler would be useful. however, I think
> before you tackle a scheduler, we need proper stored procedures. Our
> existing functions don't cut it because you can manage the transaction
> state yourself.
Did you mean
On Tue, Feb 23, 2010 at 11:08 AM, Alvaro Herrera
wrote:
> Steve Atkins wrote:
>
>> Would having a higher level process manager be adequate - one
>> that spawns the postmaster and a list of associated processes
>> (queue manager, job scheduler, random user daemons that are
>> used for database appl
Steve Atkins wrote:
> Would having a higher level process manager be adequate - one
> that spawns the postmaster and a list of associated processes
> (queue manager, job scheduler, random user daemons that are
> used for database application maintenance). It sounds like
> something like that would
On Feb 22, 2010, at 9:02 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Regarding hooks or events, I think postmaster should be kept simple:
>> launch at start, reset at crash recovery, kill at stop. Salt and pepper
>> allowed but that's about it -- more complex ingredients are out of the
>> q
Simon Riggs wrote:
> What is wanted is a means to integrate parts of a solution that are
> already intimately tied to Postgres. Non-integration makes the whole
> Postgres-based solution less reliable and harder to operate. Postgres
> should not assume that it is the only aspect of the server: in a
On Tue, 2010-02-23 at 00:02 -0500, Tom Lane wrote:
> Alvaro Herrera writes:
> > Regarding hooks or events, I think postmaster should be kept simple:
> > launch at start, reset at crash recovery, kill at stop. Salt and pepper
> > allowed but that's about it -- more complex ingredients are out of t
Dimitri Fontaine wrote:
> Tom Lane writes:
> > Alvaro Herrera writes:
> >> Regarding hooks or events, I think postmaster should be kept simple:
> >> launch at start, reset at crash recovery, kill at stop.
> >
> > This is exactly why I think the whole proposal is a nonstarter. It is
> > necessari
Tom Lane writes:
> Alvaro Herrera writes:
>> Regarding hooks or events, I think postmaster should be kept simple:
>> launch at start, reset at crash recovery, kill at stop.
>
> This is exactly why I think the whole proposal is a nonstarter. It is
> necessarily pushing more complexity into the po
Alvaro Herrera writes:
> Regarding hooks or events, I think postmaster should be kept simple:
> launch at start, reset at crash recovery, kill at stop. Salt and pepper
> allowed but that's about it -- more complex ingredients are out of the
> question due to added code to postmaster, which we wan
David Christensen wrote:
> What are the semantics? If you launch a process and it crashes, is
> the postmaster responsible for relaunching it? Is there any
> additional monitoring of that process it would be expected to do?
> What defined hooks/events would you want to launch these processes
> f
On Feb 22, 2010, at 5:22 PM, Jaime Casanova wrote:
On Mon, Feb 22, 2010 at 4:37 PM, Tom Lane wrote:
Dimitri Fontaine writes:
Tom Lane writes:
This seems like a solution in search of a problem to me. The most
salient aspect of such processes is that they would necessarily run
as the postg
On Mon, Feb 22, 2010 at 4:37 PM, Tom Lane wrote:
> Dimitri Fontaine writes:
>> Tom Lane writes:
>>> This seems like a solution in search of a problem to me. The most
>>> salient aspect of such processes is that they would necessarily run
>>> as the postgres user
>
>> The precedent are archive a
Merlin Moncure escribió:
> Like I noted above, what people want to schedule is going to be stored
> procedures. Having both would virtually eliminate the need for
> scripting outside the database, which is a pretty big deal since
> external scripts are a real pain to keep cross platform. Since
>
Tom Lane writes:
> Well, yeah, but you *must* trust those commands because every last bit
> of your database content passes through their hands. That is not an
> argument why you need to trust a scheduling facility --- much less the
> tasks it schedules.
It seems to me that CREATE FUNCTION maint
Dimitri Fontaine writes:
> Tom Lane writes:
>> This seems like a solution in search of a problem to me. The most
>> salient aspect of such processes is that they would necessarily run
>> as the postgres user
> The precedent are archive and restore command. They do run as postgres
> user too, do
On Mon, Feb 22, 2010 at 2:53 PM, Tom Lane wrote:
> I still haven't seen a good reason for not using cron or Task Scheduler
> or other standard tools.
*) provided and popular feature in higher end databases
*) the audience you cater to expects it
*) IMO, it should simply not be necessary to inco
Tom Lane writes:
> This seems like a solution in search of a problem to me. The most
> salient aspect of such processes is that they would necessarily run
> as the postgres user
I happen to run my PGQ tickers and londiste daemons as "londiste" user
and make it a superuser (at least while install
On Mon, Feb 22, 2010 at 2:29 PM, Alvaro Herrera
wrote:
> Merlin Moncure escribió:
>
>> Like I noted above, what people want to schedule is going to be stored
>> procedures. Having both would virtually eliminate the need for
>> scripting outside the database, which is a pretty big deal since
>> ex
On Mon, Feb 22, 2010 at 3:08 PM, Jaime Casanova
wrote:
> On Mon, Feb 22, 2010 at 2:53 PM, Tom Lane wrote:
>>
>> I still haven't seen a good reason for not using cron or Task Scheduler
>> or other standard tools.
>>
>
> - marketing? don't you hate when people say: Oracle has it!?
just before some
On Mon, Feb 22, 2010 at 2:53 PM, Tom Lane wrote:
>
> I still haven't seen a good reason for not using cron or Task Scheduler
> or other standard tools.
>
- marketing? don't you hate when people say: Oracle has it!?
- user dumbness: they forgot to start daemons they need (yes, i have
seen that) or
Jaime Casanova writes:
> wrote:
>> API would be user_process_startup(), user_process_shutdown().
> so it should be a GUC, that is settable only at start time.
> we need those integrated processes at all when in a standby server?
This seems like a solution in search of a problem to me. The most
On Mon, Feb 22, 2010 at 1:50 PM, Heikki Linnakangas
wrote:
>
>> we need those integrated processes at all when in a standby server?
>
> Yes. You might want to run e.g. scheduled reports from a standby
> reporting server, launched by a scheduler process. Or backups.
>
ah! fair enough!
--
Atentam
Jaime Casanova wrote:
> > if we can do this, how should it work?
> Simon said:
> """
> Yes, I think so. Rough design...
>
> integrated_user_processes = 'x, y, z'
>
> would run x(), y() and z() in their own processes. These would execute
> after startup, or at consistent point in recovery. The cod
On Sat, Feb 20, 2010 at 8:06 PM, Joshua D. Drake wrote:
>
> That doesn't mean it isn't a really good idea. It would be nice to have
> a comprehensive job scheduling solution that allows me to continue
> abstract away from external solutions and operating system dependencies.
+1!
Aa scheduler is
On Mon, Feb 22, 2010 at 1:18 PM, Heikki Linnakangas
wrote:
> Jaime Casanova wrote:
>
>> so, is this idea (having some user processes be "tied" to postmaster
>> start/stop) going to somewhere?
>
> I've added this to the TODO list. Now we just need someone to write it.
>
if we can do this, how shou
2010/2/22 Heikki Linnakangas :
> Jaime Casanova wrote:
>> On Sun, Feb 21, 2010 at 1:11 PM, Simon Riggs wrote:
>>> There is currently no way to run a separate daemon process that runs
>>> user code as part of Postgres, so that the startup code gets run
>>> immediately we startup, re-run if we crash
Jaime Casanova wrote:
> On Sun, Feb 21, 2010 at 1:11 PM, Simon Riggs wrote:
>> There is currently no way to run a separate daemon process that runs
>> user code as part of Postgres, so that the startup code gets run
>> immediately we startup, re-run if we crash and shut down cleanly when
>> the se
On Sun, Feb 21, 2010 at 1:11 PM, Simon Riggs wrote:
[...]
>> Dimitri Fontaine writes:
>> > Dave Page writes:
>> >> Why not just use pgAgent? It's far more flexible than the design
>> >> you've suggested, and already exists.
>>
>> > What would it take to have it included in core,
>>
[...]
>
> The
On Sun, 2010-02-21 at 20:46 +0100, Dimitri Fontaine wrote:
> Simon Riggs writes:
> > There is currently no way to run a separate daemon process that runs
> > user code as part of Postgres, so that the startup code gets run
> > immediately we startup, re-run if we crash and shut down cleanly when
>
Simon Riggs writes:
> There is currently no way to run a separate daemon process that runs
> user code as part of Postgres, so that the startup code gets run
> immediately we startup, re-run if we crash and shut down cleanly when
> the server does. If there were some way to run arbitrary code in a
On Sun, Feb 21, 2010 at 1:11 PM, Simon Riggs wrote:
> On Sat, 2010-02-20 at 18:19 -0500, Tom Lane wrote:
>> Dimitri Fontaine writes:
>> > Dave Page writes:
>> >> Why not just use pgAgent? It's far more flexible than the design
>> >> you've suggested, and already exists.
>>
>> > What would it tak
On Sun, Feb 21, 2010 at 1:05 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Feb 21, 2010 at 10:17 AM, Lucas wrote:
>>> I wonder if the scheduler already existed before the
>>> implementation of the autovacuum, its implementation would
>>> not be a function executed by the in-core schedul
On Sat, 2010-02-20 at 18:19 -0500, Tom Lane wrote:
> Dimitri Fontaine writes:
> > Dave Page writes:
> >> Why not just use pgAgent? It's far more flexible than the design
> >> you've suggested, and already exists.
>
> > What would it take to have it included in core,
>
> I don't think this reall
Robert Haas writes:
> On Sun, Feb 21, 2010 at 10:17 AM, Lucas wrote:
>> I wonder if the scheduler already existed before the
>> implementation of the autovacuum, its implementation would
>> not be a function executed by the in-core scheduler?
> The real genius of autovacuum is that it works ou
On Sun, Feb 21, 2010 at 10:17 AM, Lucas wrote:
> I wonder if the scheduler already existed before the
> implementation of the autovacuum, its implementation would
> not be a function executed by the in-core scheduler?
The real genius of autovacuum is that it works out when there has been
enough
On Sun, Feb 21, 2010 at 12:33 PM, Tom Lane wrote:
> Ron Mayer writes:
>> Is the real need here for a convenient way to enable and/or
>> recommend packagers to install some non-core modules by default?
>
> It would certainly help us resist assorted requests to put everything
> including the kitche
Ron Mayer writes:
> Is the real need here for a convenient way to enable and/or
> recommend packagers to install some non-core modules by default?
It would certainly help us resist assorted requests to put everything
including the kitchen sink into core.
regards, tom lane
Lucas wrote:
> I believe that "in core" may be "installed by default" in case of
Those seem like totally orthogonal concepts to me.
A feature may be "in core" but not "installed by default" (like many PLs).
A feature might not be "in core" but "installed" by many installers (say
postgis).
I
2010/2/20 Andrew Dunstan
>
> We're not going to change that because some companies have
> insane corporate policies.
I agree, Andrew...
This is an outside benefit...
not a reason or justification...
I believe that a general purpose scheduler is similar to
the autovacuum... it is not really nee
Pavel Stehule wrote:
> 2010/2/21 Andrew Dunstan :
> >> ? ?I believe that "in core" may be "installed by default" in case of
> >> ? ?the pgAgent or similar solution...
> >>
> >> ? ?Many big companies does not allow the developers to configure and
> >> ? ?install components we need to request eve
Pavel Stehule wrote:
This reasoning just doesn't fly in the PostgreSQL world. PostgreSQL is
designed to be extensible, not a monolithic product. We're not going to
change that because some companies have insane corporate policies. The
answer, as Jefferson said in another context, is to "inform
Greg Stark writes:
> It'll always be another (set of) processes even if it's "in core". All
> it means to be "in core" is that it will be harder to make
> modifications and you'll be tied to the Postgres release cycle.
Another set of processes all right, but that postmaster is responsible
of, tha
"Joshua D. Drake" writes:
> On Sat, 2010-02-20 at 18:19 -0500, Tom Lane wrote:
>> Dimitri Fontaine writes:
>> > What would it take to have it included in core,
>>
>> I don't think this really makes sense. There's basically no argument
>> for having it in core other than "I'm too lazy to install
2010/2/21 Andrew Dunstan :
>
>
> Lucas wrote:
>>
>> Tom,
>>
>> I believe that "in core" may be "installed by default" in case of
>> the pgAgent or similar solution...
>>
>> Many big companies does not allow the developers to configure and
>> install components we need to request eve
Ah! wxWidgets... Yes, i knew there was something i didn't like about
pgAgent. So is not as simple as installing it
2010/2/20, Dave Page :
> On Sat, Feb 20, 2010 at 10:03 PM, Dimitri Fontaine
> wrote:
>> Dave Page writes:
>>> Why not just use pgAgent? It's far more flexible than the design
>>> yo
On Feb 20, 2010, at 8:06 PM, "Joshua D. Drake"
wrote:
> There is zero technical reason for this to be in core.
>
> That doesn't mean it isn't a really good idea. It would be nice to
> have
> a comprehensive job scheduling solution that allows me to continue
> abstract away from external solutions
On Sat, 2010-02-20 at 18:19 -0500, Tom Lane wrote:
> Dimitri Fontaine writes:
> > Dave Page writes:
> >> Why not just use pgAgent? It's far more flexible than the design
> >> you've suggested, and already exists.
>
> > What would it take to have it included in core,
>
> I don't think this reall
On Sun, Feb 21, 2010 at 12:38 AM, Jaime Casanova
wrote:
> On Sat, Feb 20, 2010 at 7:32 PM, Dave Page wrote:
>> On Sun, Feb 21, 2010 at 12:03 AM, Jaime Casanova
>> wrote:
>>> On Sat, Feb 20, 2010 at 4:37 PM, Dave Page wrote:
On Sat, Feb 20, 2010 at 9:33 PM, Jaime Casanova
wrote:
>
Lucas wrote:
Tom,
I believe that "in core" may be "installed by default" in case of
the pgAgent or similar solution...
Many big companies does not allow the developers to configure and
install components we need to request everthing in 10 copies
of forms...
By mak
On Sat, Feb 20, 2010 at 10:03 PM, Dimitri Fontaine
wrote:
> Dave Page writes:
>> Why not just use pgAgent? It's far more flexible than the design
>> you've suggested, and already exists.
>
> What would it take to have it included in core, so that it's not a
> separate install to do? I'd love to h
On Sat, Feb 20, 2010 at 7:32 PM, Dave Page wrote:
> On Sun, Feb 21, 2010 at 12:03 AM, Jaime Casanova
> wrote:
>> On Sat, Feb 20, 2010 at 4:37 PM, Dave Page wrote:
>>> On Sat, Feb 20, 2010 at 9:33 PM, Jaime Casanova
>>> wrote:
Hi,
I'm trying to figure out how difficult is this
>>>
On Sat, Feb 20, 2010 at 11:55 PM, Lucas wrote:
> I believe that a database scheduler would allow me to drop 20 thousand lines
> of java code in my server...
How does that work? If you don't have a scheduler in the database, or
pgAgent, why aren't you using cron or Windows task scheduler, neither
On Sun, Feb 21, 2010 at 12:03 AM, Jaime Casanova
wrote:
> On Sat, Feb 20, 2010 at 4:37 PM, Dave Page wrote:
>> On Sat, Feb 20, 2010 at 9:33 PM, Jaime Casanova
>> wrote:
>>> Hi,
>>>
>>> I'm trying to figure out how difficult is this
>>
>> Why not just use pgAgent? It's far more flexible than the
On Sat, Feb 20, 2010 at 4:37 PM, Dave Page wrote:
> On Sat, Feb 20, 2010 at 9:33 PM, Jaime Casanova
> wrote:
>> Hi,
>>
>> I'm trying to figure out how difficult is this
>
> Why not just use pgAgent? It's far more flexible than the design
> you've suggested, and already exists.
>
- it's not that
Tom,
I believe that "in core" may be "installed by default" in case of the
pgAgent or similar solution...
Many big companies does not allow the developers to configure and install
components we need to request everthing in 10 copies of forms...
By making it "in core" or "installed by default
Dimitri Fontaine writes:
> Dave Page writes:
>> Why not just use pgAgent? It's far more flexible than the design
>> you've suggested, and already exists.
> What would it take to have it included in core,
I don't think this really makes sense. There's basically no argument
for having it in core
On Sat, Feb 20, 2010 at 10:03 PM, Dimitri Fontaine
wrote:
> What would it take to have it included in core, so that it's not a
> separate install to do? I'd love to have some support for running my
> maintenance pl functions directly from the database. I mean without
> installing, running and moni
>
> pg_job (
> oid -- use the oid as pk
> jobname
> jobdatoid -- job database oid
> jobowner -- for permission's checking
> jobstarttime -- year to minute
> jobfrequency -- an interval?
> jobnexttime or joblasttime
> jobtype -- if we ar
Dave Page writes:
> Why not just use pgAgent? It's far more flexible than the design
> you've suggested, and already exists.
What would it take to have it included in core, so that it's not a
separate install to do? I'd love to have some support for running my
maintenance pl functions directly fr
On Sat, Feb 20, 2010 at 4:33 PM, Jaime Casanova
wrote:
> Hi,
>
> I'm trying to figure out how difficult is this
>
> What we need:
> - a shared catalog
> - an API for filling the catalog
> - a scheduler daemon
> - pg_dump support
>
>
> A shared catalog
> -
> Why shared? obvi
On Sat, Feb 20, 2010 at 9:33 PM, Jaime Casanova
wrote:
> Hi,
>
> I'm trying to figure out how difficult is this
Why not just use pgAgent? It's far more flexible than the design
you've suggested, and already exists.
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
--
Sent via pgsql-ha
Hi,
I'm trying to figure out how difficult is this
What we need:
- a shared catalog
- an API for filling the catalog
- a scheduler daemon
- pg_dump support
A shared catalog
-
Why shared? obviously because we don't want to scan all database's
pg_job every time the daemon
65 matches
Mail list logo
