From: Simon Riggs <simon@2ndquadrant.com>
To: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Infrastructure changes for recovery
Date: Thu, 07 Aug 2008 12:44:19 +0100
Message-ID: <1218109459.4549.423.camel@ebony.2ndQuadrant> (raw)
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.com
PostgreSQL Training, Services and Support
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-patches@postgresql.org
Cc: simon@2ndquadrant.com, pgsql-hackers@postgresql.org
Subject: Re: Infrastructure changes for recovery
In-Reply-To: <1218109459.4549.423.camel@ebony.2ndQuadrant>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox