I would like to propose some changes to the infrastructure for recovery.
These changes are beneficial in themselves, but also form the basis for
other work we might later contemplate.
Currently
* the startup process performs restartpoints during recovery
* the death of the startup process is tied directly to the change of
state in the postmaster following recovery
I propose to
* have startup process signal postmaster when it starts Redo phase (if
it starts it)
* 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
Decoupling things in this way allows us to
1. arrange for the bgwriter to start during Redo, so it can:
i) clean dirty blocks for the startup process
ii) perform restartpoints in background Both of these aspects will increase performance of recovery
2. provide a starting point for other changes in both startup process
and postmaster. These would include
i) have startup process do other work after startup completes, such as
executing transactions to rebuild damaged indexes, etc
ii) have postmaster allow connections while Redo is taking place, as one
part of allowing query access to standby database
The above two points have not been discussed and require separate
justification. However, any work on them is impossible without these
infrastructure changes.
These changes are part of a general strategy of moving in beneficial
steps towards various other goals, rather than attempting to create a
super-patch on 1 Nov that conflicts with other patches incoming at that
time. These parts are likely to conflict with synch replication work, so
I want to resolve as much as possible on Sept Commitfest.
The patch would include the required changes for bgwriter also.
Any objections/alterations to these proposals, please?
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
