On Tue, Feb 6, 2024 at 1:09 PM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > On Tue, Feb 6, 2024 at 3:19 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > I think users can refer to LOGs to see if it has changed since the > > first time it was configured. I tried by existing parameter and see > > the following in LOG: > > LOG: received SIGHUP, reloading configuration files > > 2024-02-06 11:38:59.069 IST [9240] LOG: parameter "autovacuum" changed to > > "on" > > > > If the user can't confirm then it is better to follow the steps > > mentioned in the patch. Do you want something else to be written in > > docs for this? If so, what? > > IIUC even if a wrong slot name is specified to standby_slot_names or > even standby_slot_names is empty, the standby server might not be > lagging behind the subscribers depending on the timing. But when > checking it the next time, the standby server might lag behind the > subscribers. So what I wanted to know is how the user can confirm if a > failover-enabled subscription is ensured not to go in front of > failover-candidate standbys (i.e., standbys using the slots listed in > standby_slot_names). >
But isn't the same explained by two steps ((a) Firstly, on the subscriber node check the last replayed WAL. (b) Next, on the standby server check that the last-received WAL location is ahead of the replayed WAL location on the subscriber identified above.) in the latest *_0004 patch. -- With Regards, Amit Kapila.
