Prev: Reason why set-value functions not allowed in GREATEST(), etc?
Next: tie user processes to postmaster was:(Re: [HACKERS] scheduler in core)
From: Jaime Casanova on 22 Feb 2010 13:34 On Mon, Feb 22, 2010 at 1:18 PM, Heikki Linnakangas <heikki.linnakangas(a)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 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. we need those integrated processes at all when in a standby server? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL AsesorÃa y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |