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 |
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 |