Re: [HACKERS] Restricting maximum keep segments by repslots

At Tue, 31 Mar 2020 14:18:36 -0300, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote in
> On 2020-Mar-31, Alvaro Herrera wrote:
>
> > I'm not sure if I explained my proposal clearly. What if
> > XLogGetLastRemovedSegno returning zero means that every segment is
> > valid? We don't need to scan pg_xlog at all.
>
> I mean this:
>
> XLogSegNo
> FindOldestXLogFileSegNo(void)
> {
> XLogSegNo segno = XLogGetLastRemovedSegno();
>
> /* this is the only special case we need to care about */
> if (segno == 0)
> return some-value;
>
> return segno + 1;
> }
>
> ... and that point one can further note that a freshly initdb'd system
> (no file has been removed) has "1" as the first file. So when segno is
> 0, you can return 1 and all should be well. That means you can reduce
> the function to this:

If we don't scan the wal files, for example (somewhat artificail), if
segments canoot be removed by a wrong setting of archive_command,
GetWalAvailability can return false "removed(lost)" state. If
max_slot_wal_keep_size is shrinked is changed then restarted, the
function can return false "normal" or "keeping" states.

By the way the oldest segment of initdb'ed cluster was (14x)th for
me. So I think we can treat segno == 1 as "uncertain" or "unknown"
state, but that state lasts until a checkpoint actually removes a
segment.

> XLogSegNo
> FindOldestXLogFileSegNo(void)
> {
> return XLogGetLastRemovedSegno() + 1;
> }
>
>
> The tests still pass with this coding.

Mmm. Yeah, that affects when under an abnormal condition.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center