Re: PITR COPY Failure (was Point in Time Recovery) - Mailing list pgsql-hackers

On Tue, 2004-07-20 at 13:51, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> >> The quick and dirty solution would be to dike out the safety check at
> >> 4268ff.  
> 
> > If you take out that check, we still fail because the wasted space at
> > the end is causing a "record with zero length" error.
> 
> Ugh.  I'm beginning to think we ought to revert the patch that added the
> don't-split-across-files logic to XLogInsert; that seems to have broken
> more assumptions than I realized.  That was added here:
> 
> 2004-02-11 17:55  tgl
> 
>     * src/: backend/access/transam/xact.c,
>     backend/access/transam/xlog.c, backend/access/transam/xlogutils.c,
>     backend/storage/smgr/md.c, backend/storage/smgr/smgr.c,
>     bin/pg_controldata/pg_controldata.c,
>     bin/pg_resetxlog/pg_resetxlog.c, include/access/xact.h,
>     include/access/xlog.h, include/access/xlogutils.h,
>     include/pg_config_manual.h, include/catalog/pg_control.h,
>     include/storage/smgr.h: Commit the reasonably uncontroversial parts
>     of J.R. Nield's PITR patch, to wit: Add a header record to each WAL
>     segment file so that it can be reliably identified.  Avoid
>     splitting WAL records across segment files (this is not strictly
>     necessary, but makes it simpler to incorporate the header records).
>      Make WAL entries for file creation, deletion, and truncation (as
>     foreseen but never implemented by Vadim).  Also, add support for
>     making XLOG_SEG_SIZE configurable at compile time, similarly to
>     BLCKSZ.  Fix a couple bugs I introduced in WAL replay during recent
>     smgr API changes.  initdb is forced due to changes in pg_control
>     contents.
> 
> There are other ways to do this, for example we could treat the WAL page
> headers as variable-size, and stick the file labeling info into the
> first page's header instead of making it be a separate record.  The
> separate-record way makes it easier to incorporate future additions to
> the file labeling info, but I don't really think it's critical to allow
> for that.
> 

I think I've fixed it now...but wait 20

The problem was that a zero length XLOG_WASTED_SPACE record just fell
out of ReadRecord when it shouldn't have. By giving it a helping hand it
makes it through with pointers correctly set, and everything else was
already thought of in the earlier patch, so xlog_redo etc happens.

I'll update again in a few minutes....no point us both looking at this.

Best regards, Simon Riggs