Re: Enhance pg_stat_wal_receiver view to display connected host

From: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Enhance pg_stat_wal_receiver view to display connected host
Date: 2018-01-15 06:51:58
Message-ID: CAJrrPGfs7=1-TUQQWTWTcXhTQn-1p1hpRy42LegPe+aWtK3QJA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jan 8, 2018 at 3:32 PM, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
wrote:

>
>
> On Fri, Jan 5, 2018 at 11:15 PM, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
> wrote:
>
>> Haribabu Kommi wrote:
>>
>> > or
>> >
>> > write two new functions PQconnhost() and PQconnhostaddr() to return the
>> > connected host and hostaddr and reuse the PQport() function.
>>
>> How about using an API similar to PQconninfo, where we return an array
>> of connection options used? Say, PQeffectiveConninfo(). This seems to
>> me to reduce ugliness in the API, and be more generally useful.
>>
>
> OK. Added the new API PQeffectiveConninfo() that returns all the connection
> options that are actively used. Currently the connection options host,
> hostaddr
> and port may change based on the active connection and rest of the options
> may be same.
>
> walrecvr could display as an array or just flatten to a string -- not
>> sure what's the better option there.
>
>
> Currently I went with a string model to display all the effective_conninfo
> options. I feel if we go with string approach, adding a new option that
> gets
> updated in future is simple.
>
> postgres=# select conninfo, effective_conninfo from pg_stat_wal_receiver;
> -[ RECORD 1 ]------+----------------------------------------------------
> ------------------------------------------------------------
> ------------------------------------------------------------
> -------------------------------------------------
> conninfo | user=kommih passfile=/home/kommih/.pgpass
> dbname=replication hostaddr=127.0.0.1,127.0.0.1 port=5434,5432
> application_name=s2 fallback_application_name=walreceiver sslmode=disable
> sslcompression=1 target_session_attrs=any
> effective_conninfo | user=kommih passfile=/home/kommih/.pgpass
> dbname=replication hostaddr=127.0.0.1 port=5432 application_name=s2
> fallback_application_name=walreceiver sslmode=disable sslcompression=1
> target_session_attrs=any
>
>
> Majority of the options are same in both conninfo and effective_conninfo
> columns.
> Instead of "effective_conninfo" column, how about something like
> "remote_server"
> as string that displays only the host, hostaddr and port options that
> differs with
> each connection?
>

Instead of effective_conninfo, I changed the column name as
remote_serve_info and
display only the host, hostaddr and port details. These are the only values
that differs
with each remote connection.

patches attached.

Regards,
Hari Babu
Fujitsu Australia

Attachment Content-Type Size
0001-Addition-of-new-libpq-API-PQeffectiveconninfo.patch application/octet-stream 5.2 KB
0002-remote_server_info-column-addtion-to-pg_stat_wal_rec.patch application/octet-stream 11.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2018-01-15 07:25:37 Re: BUG #14999: pg_rewind corrupts control file global/pg_control
Previous Message Kyotaro HORIGUCHI 2018-01-15 06:36:32 Re: [HACKERS] Restricting maximum keep segments by repslots