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
Jaime Casanova wrote:
> integrated_user_processes = 'x, y, z'
> API would be user_process_startup(), user_process_shutdown().
FYI, pg_statsinfo version 2 emulates the same behavior with
shared_preload_libraries and spawn an user process in _PG_init().
But it's still ugly and not so reliable. Of
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
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 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 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
22 matches
Mail list logo
