On Wed, Aug 25, 2021 at 5:43 PM Ajin Cherian <itsa...@gmail.com> wrote: > > On Wed, Aug 25, 2021 at 4:22 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > On Wed, Aug 25, 2021 at 8:00 AM Ajin Cherian <itsa...@gmail.com> wrote: > > > > > > On Tue, Aug 24, 2021 at 11:12 PM Amit Kapila <amit.kapil...@gmail.com> > > > wrote: > > > > > > > But will poll function still poll or exit? Have you tried that? > > > > > > I have forced that condition with a changed query and found that the > > > poll will not exit in case of a NULL return. > > > > > > > What if the query in a poll is fired just before we get an error > > "tap_sub ERROR: replication slot "tap_sub" is active for PID 16336"? > > Won't at that stage both old and new walsender's are present, so the > > query might return true. You can check that via debugger by stopping > > just before this error occurs and then check pg_stat_replication view. > > If this error happens then the PID is NOT updated as the pid in the > Replication slot. I have checked this > and explained this in my first email itself >
Sorry about the above email, I misunderstood. I was looking at pg_stat_replication_slot rather than pg_stat_replication hence the confusion. Amit is correct, just prior to the walsender erroring out, it briefly appears in the pg_stat_replication, and that is why this error happens. Sorry for the confusion. I just confirmed it, got both the walsenders stopped in the debugger: postgres=# select pid from pg_stat_replication where application_name = 'sub'; pid ------ 7899 7993 (2 rows) ajin 7896 3326 0 05:22 pts/2 00:00:00 psql -p 6972 postgres ajin 7897 7882 0 05:22 ? 00:00:00 postgres: ajin postgres [local] idle ajin 7899 7882 0 05:22 ? 00:00:00 postgres: walsender ajin ::1(37719) START_REPLICATION ajin 7992 3647 0 05:24 ? 00:00:00 postgres: logical replication worker for subscription 16426 ajin 7993 7882 0 05:24 ? 00:00:00 postgres: walsender ajin ::1(37720) START_REPLICATION regards, Ajin Cherian Fujitsu Australia
