Re: PITR COPY Failure (was Point in Time Recovery)

On Tue, 2004-07-20 at 13:51, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)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