Re: [HACKERS] Restricting maximum keep segments by repslots

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