On Fri, Dec 29, 2023 at 7:18 AM Masahiko Sawada <sawada.m...@gmail.com> wrote:
>
> On Wed, Dec 27, 2023 at 7:13 PM shveta malik <shveta.ma...@gmail.com> wrote:
> >
> > On Wed, Dec 27, 2023 at 11:36 AM Masahiko Sawada <sawada.m...@gmail.com>
> > wrote:
>
> > I was not aware if there is any way to connect if we
> > want to run SQL queries. I initially tried using 'PQconnectdbParams'
> > but couldn't make it work. Perhaps it is to be used only by front-end
> > and extensions as the header files indicate as well:
> > * libpq-fe.h : This file contains definitions for structures and
> > externs for functions used by frontend postgres applications.
> > * libpq-be-fe-helpers.h: Helper functions for using libpq in
> > extensions . Code built directly into the backend is not allowed to
> > link to libpq directly.
>
> Oh I didn't know that. Thank you for pointing it out.
>
> But I'm still concerned it could confuse users that
> pg_stat_replication keeps showing one entry that remains as "startup"
> state. It has the same application_name as the walreceiver uses. For
> example, when users want to check the particular replication
> connection, it's common to filter the entries by the application name.
> But it will end up having duplicate entries having different states.
>
Valid point. The main reason for using cluster_name is that if
multiple standby's connect to the same primary, all will have the same
application_name as 'slotsyncworker'. The other alternative could be
to use {cluster_name}_slotsyncworker, which will probably address your
concern and we can have to provision to differentiate among
slotsyncworkers from different standby's.
--
With Regards,
Amit Kapila.
