On Thu, 2008-08-07 at 10:56 -0400, Alvaro Herrera wrote:
> > * have startup process signal postmaster again when it has completed
> > recovery, so that the change of state is via explicit signal rather than
> > death of the child process
>
> I'm not sure that this is very useful, because the startup process
> cannot do anything much. It is an auxiliary process, which means it
> can't connect to a database and it can't run transactions.
Yes, but its going to be a lot easier to make it do transactions than it
will be to spawn something else that does? Or so I thought...
Specifically, I want to have a rmgr_post_cleanup() call to perform such
actions.
Who do you think should run those calls? They might need transactions,
or not, depending upon the rmgr. I envisage initially that rmgrs could
mark indexes as Invalid in pg_class, which requires a transaction (or
does it?).
If we did alter rmgrs to allow them to actually rebuild an index, then
it would be desirable to have them do it in parallel, just like AV
workers.
Would it be possible to use have startup to run rmgr_post_cleanup, then
provide a facility to have them run tasks through AV workers?
Sounds like a separate patch anyway.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support