BUG #18945: Standby synchronization problem

On Mon, Jun 2, 2025 at 5:56 PM PG Bug reporting form
<noreply@postgresql.org> wrote:

The following bug has been logged on the website:

Bug reference: 18945
Logged by: lucas marola
Email address: lucasmarola@hotmail.com
PostgreSQL version: 16.8
Operating system: Red Hat Enterprise Linux release 9.5 (Plow)
Description:

Sometimes, the WAL application on the standby environment takes a long time
to complete. However, after restarting the application process, it returns
to normal.

it's difficult to pinpoint the exact problem with the information
provided. However, a common scenario involves read-only queries on a
standby database conflicting with the WAL apply process. And as a
result of restarting the application it will terminate all the backend
so you are not facing issues of conflict any more. You can check the
value of 'max_standby_streaming_delay' as this will control how long
the WAL apply process should wait in case of a conflict with the
snapshot of the local queries. If you have steps to reproduce/or more
details on the exact scenario, then that would be helpful.

--
Regards,
Dilip Kumar
Google

On Mon, Jun 02, 2025 at 06:42:08PM +0530, Dilip Kumar wrote:

it's difficult to pinpoint the exact problem with the information
provided. However, a common scenario involves read-only queries on a
standby database conflicting with the WAL apply process. And as a
result of restarting the application it will terminate all the backend
so you are not facing issues of conflict any more. You can check the
value of 'max_standby_streaming_delay' as this will control how long
the WAL apply process should wait in case of a conflict with the
snapshot of the local queries.

Indeed, there could be a lot going on.

A sequence of commands to pinpoint an issue, with a precise
description of what has been done, would help. Their may be some
tools you are using, that help in the reproducibility. If you are
seeing a process being stuck, attaching gdb to the process that
matters, be it a WAL sender or the startup process, or something else,
can also provide useful hints that could help in determining if you
have hit an actual bug or not. Log contents could provide useful
hints, just be sure to trim any sensitive contents they may include
before posting or attaching anything here.

Three lines to describe your problem is not enough for one to
potentially understand what's going on in your system.

If you have steps to reproduce/or more
details on the exact scenario, then that would be helpful.

Right.
--
Michael