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