On Tue, 2010-04-06 at 10:22 +0100, Simon Riggs wrote:
> Initial patch. I will be testing over next day. No commit before at
> least midday on Wed 7 Apr.
Various previous discussions sidelined a very important point: what
exactly does it mean to "start recovery from a shutdown checkpoint"?
If standby_mode is enabled and there is no source of WAL, then we get a
stream of messages saying
LOG: record with zero length at 0/C000088
...
but most importantly we never get to the main recovery loop, so Hot
Standby never gets to start at all. We can't keep retrying the request
for WAL and at the same time enter the retry loop, executing lots of
things that expect non-NULL pointers using a NULL xlog pointer.
What we are asking for here is a completely new state: the database is
not "in recovery" - by definition there is nothing at all to recover.
The following patch adds "Snapshot Mode", a very simple variation on the
existing code - emphasis on the "simple":
LOG: entering snapshot mode
LOG: record with zero length at 0/C000088
LOG: consistent recovery state reached at 0/C000088
LOG: database system is ready to accept read only connections
this mode does *not* continually check to see if new WAL files have been
added. Startup just sits and waits, backends allowed. If a trigger file
is specified, then we can leave recovery. Otherwise Startup process just
sits doing nothing.
There's possibly an argument for inventing some more special modes where
we do allow read only connections but don't start the bgwriter. I don't
personally wish to do this at this stage of the release cycle. The
attached patch is non-invasive and safe and I want to leave it at that.
I will be committing later today, unless major objections, but I ask you
to read the patch before you sharpen your pen. It's simple.
--
Simon Riggs www.2ndQuadrant.com