On Mon, 2006-08-07 at 09:48 -0400, Tom Lane wrote:
> I'm in process of reviewing the restartable-recovery patch,
> http://archives.postgresql.org/pgsql-patches/2006-07/msg00356.php
> and I'm wondering if we really need to invent a "standby mode" boolean
> to get the right behavior. The problem I see with that flag is that
> it'd be static over a run, whereas the behavior we want is dynamic.
> It seems entirely likely that a slave will be started from a base backup
> that isn't quite current, and will need to run through some archived WAL
> segments quickly before it catches up to the master. So during the
> catchup period we'd prefer that it not do restartpoints one-for-one
> with the logged checkpoints, whereas after it's caught up, that's what
> we want.
That's a great observation. It also ties in neatly with the last piece
of function I've been trying to add.
Let's have it run at full speed, i.e. restartpoint every 100 checkpoints
up until we hit end-of-logs, then if we are not in standby_mode the
recovery will just end. [Also: Currently, we do not retry a request for
a archive file during recovery, though for balance with archive we
should retry 3 times.]
If we are in standby mode, then rather than ending recovery we go into a
wait loop. We poll for the next file, then sleep for 1000 ms, then poll
again. When a file arrives we mark a restartpoint each checkpoint.
We need the standby_mode to signify the difference in behaviour at
end-of-logs, but we may not need a parameter of that exact name.
The piece I have been puzzling over is how to initiate a failover when
in standby_mode. I've not come up with a better solution than checking
for the existence of a trigger file each time round the next-file wait
loop. This would use a naming convention to indicate the port number,
allowing us to uniquely identify a cluster on any single server. That's
about as portable and generic as you'll get.
We could replace the standby_mode with a single parameter to indicate
where the trigger file should be located.
This is then the last piece in the standby server puzzle.
-- Simon Riggs EnterpriseDB http://www.enterprisedb.com
