On Wed, 18 Jun 2025 at 14:35, Vitaly Davydov <v.davydov@postgrespro.ru> wrote:
>
> Dear Hayato,
>
> > To confirm, can you tell me the theory why the walsender received old LSN?
> > It is sent by the walreceiver, so is there a case that LogstreamResult.Flush can go backward?
> > Not sure we can accept the situation.
>
> I can't say anything about the origin of the issue, but it can be easily reproduced
> on the master branch:
>
> 1. Add an assert in PhysicalConfirmReceivedLocation (apply the attached patch)
> 2. Compile & install with tap tests and assertions enabled
> 3. cd src/bin/pg_basebackup/
> 3. PROVE_TESTS=t/020_pg_receivewal.pl gmake check
Thanks for the steps, I was able to reproduce the issue with the
suggested steps.
> The test will fail because of the assertion. I plan to investigate the issue
> but I need some more time for it. Once, it happens on the original master
> branch, I think, this problem already exists. The proposed patch seems
> to be not guilty.
This issue occurs even prior to this commit, I was able to reproduce
it on a version just before it. I’ll also look into analyzing the root
cause further.
> It may be the same problem as discussed in:
> https://www.postgresql.org/message-id/CALDaNm2uQbhEVJzvnja6rw7Q9AYu9FpVmET%3DTbwLjV3DcPRhLw%40mail.gmail.com
This issue was related to confirmed_flush and was addressed in commit
d1ffcc7fa3c54de8b2a677a3e503fc808c7b419c. It is not related to
restart_lsn.
Regards,
Vignesh
