On Fri, Oct 26, 2018 at 11:26:36AM +0900, Kyotaro HORIGUCHI wrote: > The reason for doing that in the fucntion is it can happen also > for physical replication when walsender is active but far > behind. The removed(renamed)-but-still-open segment may be > recycled and can be overwritten while reading, and it will be > caught by page/record validation. It is substantially lost in > that sense. I don't think the strictness is useful for anything..
I was just coming by to look at bit at the patch series, and bumped
into that:
> + /*
> + * checkpoint can remove the segment currently looking for. make sure
> the
> + * current segment is still exists. We check this only once per record.
> + */
> + XLByteToSeg(targetPagePtr, targetSegNo, state->wal_segment_size);
> + if (targetSegNo <= XLogGetLastRemovedSegno())
> + ereport(ERROR,
> + (errcode(ERRCODE_NO_DATA),
> + errmsg("WAL record at %X/%X no longer
> available",
> + (uint32)(RecPtr >> 32),
> (uint32) RecPtr),
> + errdetail("The segment for the record has been
> removed.")));
> +
ereport should not be called within xlogreader.c as a base rule:
* This file is compiled as both front-end and backend code, so it
* may not use ereport, server-defined static variables, etc.
--
Michael
signature.asc
Description: PGP signature
