Re: tie user processes to postmaster was:(Re: [HACKERS] scheduler in core) - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: tie user processes to postmaster was:(Re: [HACKERS] scheduler in core)
Date
Msg-id 4B82D1F9.2040004@enterprisedb.com
Whole thread Raw
In response to tie user processes to postmaster was:(Re: [HACKERS] scheduler in core)  (Jaime Casanova <jcasanov@systemguards.com.ec>)
Responses Re: tie user processes to postmaster was:(Re: [HACKERS] scheduler in core)
List pgsql-hackers
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
> would come from preload_libraries etc.
> 
> They would not block smart shutdown, though their shudown sequence might
> delay it. User code would be executed last at startup and first thing at
> shutdown.
> 
> API would be user_process_startup(), user_process_shutdown().
> """
> 
> so it should be a GUC, that is settable only at start time.

A GUC like that was my first thought too. We've already come up with
many uses for it, so whatever the interface is, will need to make sure
it's flexible enough to cater for all the use cases.

> 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.

--  Heikki Linnakangas EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Recent vendor SSL renegotiation patches break PostgreSQL
Next
From: Jaime Casanova
Date:
Subject: Re: tie user processes to postmaster was:(Re: [HACKERS] scheduler in core)