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 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
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
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
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
21 matches
Mail list logo
