On Sat, Feb 20, 2010 at 4:41 PM, Merlin Moncure mmonc...@gmail.com 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
2010/3/1 Robert Haas robertmh...@gmail.com:
On Sat, Feb 20, 2010 at 4:41 PM, Merlin Moncure mmonc...@gmail.com 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
On Mon, Mar 1, 2010 at 4:43 PM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Feb 20, 2010 at 4:41 PM, Merlin Moncure mmonc...@gmail.com wrote:
IMNSHO, an 'in core' scheduler would be useful. however, I think
before you tackle a scheduler, we need proper stored procedures. Our
existing
Robert Haas robertmh...@gmail.com writes:
On Sat, Feb 20, 2010 at 4:41 PM, Merlin Moncure mmonc...@gmail.com 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
On Tue, Feb 23, 2010 at 11:08 AM, Alvaro Herrera
alvhe...@commandprompt.com 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
Tom Lane t...@sss.pgh.pa.us writes:
Alvaro Herrera alvhe...@commandprompt.com 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
Dimitri Fontaine wrote:
Tom Lane t...@sss.pgh.pa.us writes:
Alvaro Herrera alvhe...@commandprompt.com 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
On Tue, 2010-02-23 at 00:02 -0500, Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com 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
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
On Feb 22, 2010, at 9:02 PM, Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com 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
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 be
On Sun, 2010-02-21 at 20:46 +0100, Dimitri Fontaine wrote:
Simon Riggs si...@2ndquadrant.com 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
On Sun, Feb 21, 2010 at 1:11 PM, Simon Riggs si...@2ndquadrant.com wrote:
[...]
Dimitri Fontaine dfonta...@hi-media.com writes:
Dave Page dp...@pgadmin.org 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
Jaime Casanova wrote:
On Sun, Feb 21, 2010 at 1:11 PM, Simon Riggs si...@2ndquadrant.com 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
2010/2/22 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
Jaime Casanova wrote:
On Sun, Feb 21, 2010 at 1:11 PM, Simon Riggs si...@2ndquadrant.com 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
On Mon, Feb 22, 2010 at 1:18 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On Sat, Feb 20, 2010 at 8:06 PM, Joshua D. Drake j...@commandprompt.com 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.
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 code for these
On Mon, Feb 22, 2010 at 1:50 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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.
Jaime Casanova jcasa...@systemguards.com.ec writes:
heikki.linnakan...@enterprisedb.com 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
On Mon, Feb 22, 2010 at 2:53 PM, Tom Lane t...@sss.pgh.pa.us 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
On Mon, Feb 22, 2010 at 3:08 PM, Jaime Casanova
jcasa...@systemguards.com.ec wrote:
On Mon, Feb 22, 2010 at 2:53 PM, Tom Lane t...@sss.pgh.pa.us 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
On Mon, Feb 22, 2010 at 2:29 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
Tom Lane t...@sss.pgh.pa.us 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
On Mon, Feb 22, 2010 at 2:53 PM, Tom Lane t...@sss.pgh.pa.us 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
Dimitri Fontaine dfonta...@hi-media.com writes:
Tom Lane t...@sss.pgh.pa.us 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
Tom Lane t...@sss.pgh.pa.us 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
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
On Feb 22, 2010, at 5:22 PM, Jaime Casanova wrote:
On Mon, Feb 22, 2010 at 4:37 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Dimitri Fontaine dfonta...@hi-media.com writes:
Tom Lane t...@sss.pgh.pa.us writes:
This seems like a solution in search of a problem to me. The most
salient aspect of
On Mon, Feb 22, 2010 at 4:37 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Dimitri Fontaine dfonta...@hi-media.com writes:
Tom Lane t...@sss.pgh.pa.us 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
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
from?
Alvaro Herrera alvhe...@commandprompt.com 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
Joshua D. Drake j...@commandprompt.com writes:
On Sat, 2010-02-20 at 18:19 -0500, Tom Lane wrote:
Dimitri Fontaine dfonta...@hi-media.com 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
Greg Stark gsst...@mit.edu 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
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
Pavel Stehule wrote:
2010/2/21 Andrew Dunstan and...@dunslane.net:
? ?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
2010/2/20 Andrew Dunstan and...@dunslane.net
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
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).
It seems like
Ron Mayer rm...@cheapcomplexdevices.com 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.
On Sun, Feb 21, 2010 at 12:33 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Ron Mayer rm...@cheapcomplexdevices.com 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
On Sun, Feb 21, 2010 at 10:17 AM, Lucas luca...@gmail.com 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
Robert Haas robertmh...@gmail.com writes:
On Sun, Feb 21, 2010 at 10:17 AM, Lucas luca...@gmail.com 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
On Sat, 2010-02-20 at 18:19 -0500, Tom Lane wrote:
Dimitri Fontaine dfonta...@hi-media.com writes:
Dave Page dp...@pgadmin.org 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,
On Sun, Feb 21, 2010 at 1:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Feb 21, 2010 at 10:17 AM, Lucas luca...@gmail.com wrote:
I wonder if the scheduler already existed before the
implementation of the autovacuum, its implementation would
not
On Sun, Feb 21, 2010 at 1:11 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Sat, 2010-02-20 at 18:19 -0500, Tom Lane wrote:
Dimitri Fontaine dfonta...@hi-media.com writes:
Dave Page dp...@pgadmin.org writes:
Why not just use pgAgent? It's far more flexible than the design
you've
Simon Riggs si...@2ndquadrant.com 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
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
On Sat, Feb 20, 2010 at 9:33 PM, Jaime Casanova
jcasa...@systemguards.com.ec 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:
On Sat, Feb 20, 2010 at 4:33 PM, Jaime Casanova
jcasa...@systemguards.com.ec 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
-
Dave Page dp...@pgadmin.org 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
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 are going
On Sat, Feb 20, 2010 at 10:03 PM, Dimitri Fontaine
dfonta...@hi-media.com 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
Dimitri Fontaine dfonta...@hi-media.com writes:
Dave Page dp...@pgadmin.org 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
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 means
On Sat, Feb 20, 2010 at 4:37 PM, Dave Page dp...@pgadmin.org wrote:
On Sat, Feb 20, 2010 at 9:33 PM, Jaime Casanova
jcasa...@systemguards.com.ec 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
On Sun, Feb 21, 2010 at 12:03 AM, Jaime Casanova
jcasa...@systemguards.com.ec wrote:
On Sat, Feb 20, 2010 at 4:37 PM, Dave Page dp...@pgadmin.org wrote:
On Sat, Feb 20, 2010 at 9:33 PM, Jaime Casanova
jcasa...@systemguards.com.ec wrote:
Hi,
I'm trying to figure out how difficult is this
On Sat, Feb 20, 2010 at 11:55 PM, Lucas luca...@gmail.com 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
On Sat, Feb 20, 2010 at 7:32 PM, Dave Page dp...@pgadmin.org wrote:
On Sun, Feb 21, 2010 at 12:03 AM, Jaime Casanova
jcasa...@systemguards.com.ec wrote:
On Sat, Feb 20, 2010 at 4:37 PM, Dave Page dp...@pgadmin.org wrote:
On Sat, Feb 20, 2010 at 9:33 PM, Jaime Casanova
On Sat, Feb 20, 2010 at 10:03 PM, Dimitri Fontaine
dfonta...@hi-media.com wrote:
Dave Page dp...@pgadmin.org 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
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 making
On Sun, Feb 21, 2010 at 12:38 AM, Jaime Casanova
jcasa...@systemguards.com.ec wrote:
On Sat, Feb 20, 2010 at 7:32 PM, Dave Page dp...@pgadmin.org wrote:
On Sun, Feb 21, 2010 at 12:03 AM, Jaime Casanova
jcasa...@systemguards.com.ec wrote:
On Sat, Feb 20, 2010 at 4:37 PM, Dave Page
On Sat, 2010-02-20 at 18:19 -0500, Tom Lane wrote:
Dimitri Fontaine dfonta...@hi-media.com writes:
Dave Page dp...@pgadmin.org 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,
On Feb 20, 2010, at 8:06 PM, Joshua D. Drake j...@commandprompt.com
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
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 dp...@pgadmin.org:
On Sat, Feb 20, 2010 at 10:03 PM, Dimitri Fontaine
dfonta...@hi-media.com wrote:
Dave Page dp...@pgadmin.org writes:
Why not just use
2010/2/21 Andrew Dunstan and...@dunslane.net:
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
65 matches
Mail list logo
