Infrastructure changes for recovery
От | Simon Riggs |
---|---|
Тема | Infrastructure changes for recovery |
Дата | |
Msg-id | 1218109459.4549.423.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответы |
Re: Infrastructure changes for recovery
Re: Infrastructure changes for recovery |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: