Re: PITR Recovery

On Wed, 2004-06-16 at 02:49, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:

> > Implementation wise, I would expect all of this code to go in xlog.c,
> > with the recovery target code living in ReadRecord().
> 
> I'd like to keep it out of there, as xlog.c is far too big and complex
> already.  Not sure where else though.  Maybe we need to break down
> xlog.c somehow.
> 

Yes, I would very much like to split out the recovery code into a
different file, so that all recovery code was all in one place.

Refactoring in this way would protect further PITR work from conflicting
with other changes in the last minute rush, as well as making most
future recovery changes a single file patch (well...nearly...)

xlogutils.c is already almost fully dedicated to recovery code, so it
seems like a good place to centralise, even though I don't like the
name!

Looking at the code, I would suggest:

--Move these code sections into void X (void) functions that would
reside in xlogutils.c but get called from StartupXLog in xlog.c,
currently within if (InRecovery) {} braces:
Add StartupRecovery() - main REDO recovery
from 
---/* REDO */if (InRecovery){
--- to                (errmsg("redo is not required")));}
/* * Init xlog buffer cache using the block containing the last valid
---
Add CleanupRecovery() - cleanup after recovery
..similarly

that would then allow us to 
--Move the following to xlogutils.c  XLogInitRelationCache  RestoreBkpBlocks  ReadRecord (may need still to be called
fromxlog.c)     RecordIsValid     ValidXLOGHeader  XLogCloseRelationCache
 

--Remove from xlogutils.h
extern void XLogInitRelationCache(void);
extern void XLogCloseRelationCache(void);

replace with 

extern void StartupRecovery(void);
extern void CleanupRecovery(void);

Is that something you'd be able to do as a starting point for the other
changes? It's easier for a committer to do this, than for me to do it
and then another to review it...

Best Regards, Simon Riggs