On Fri, Apr 28, 2023 at 2:24 PM Drouvot, Bertrand
<bertranddrouvot.pg@gmail.com> wrote:
>
> > Can you
> > please explain the logic behind this test a bit more like how the WAL
> > file switch helps you to achieve the purpose?
> >
>
> The idea was to generate enough "wal switch" on the primary to ensure
> the WAL file has been removed.
>
> I gave another thought on it and I think we can skip the test that the WAL is
> not on the primary any more. That way, one "wal switch" seems to be enough
> to see it removed on the standby.
>
> It's done in V7.
>
> V7 is not doing "extra tests" than necessary and I think it's probably better like this.
>
> I can see V7 failing on "Cirrus CI / macOS - Ventura - Meson" only (other machines are not complaining).
>
> It does fail on "invalidated logical slots do not lead to retaining WAL", see
https://cirrus-ci.com/task/4518083541336064
>
> I'm not sure why it is failing, any idea?
>
I think the reason for the failure is that on standby, the test is not
able to remove the file corresponding to the invalid slot. You are
using pg_switch_wal() to generate a switch record and I think you need
one more WAL-generating statement after that to achieve your purpose
which is that during checkpoint, the tes removes the WAL file
corresponding to an invalid slot. Just doing checkpoint on primary may
not serve the need as that doesn't lead to any new insertion of WAL on
standby. Is your v6 failing in the same environment? If not, then it
is probably due to the reason that the test is doing insert after
pg_switch_wal() in that version. Why did you change the order of
insert in v7?
BTW, you can confirm the failure by changing the DEBUG2 message in
RemoveOldXlogFiles() to LOG. In the case, where the test fails, it may
not remove the WAL file corresponding to an invalid slot whereas it
will remove the WAL file when the test succeeds.
--
With Regards,
Amit Kapila.