Re: [Todo item] Add entry creation timestamp column to pg_stat_replication

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: myungkyu(dot)lim(at)samsung(dot)com, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, woosung(dot)sohn(at)samsung(dot)com, don(dot)hong(at)samsung(dot)com
Subject: Re: [Todo item] Add entry creation timestamp column to pg_stat_replication
Date: 2018-11-22 07:53:21
Message-ID: 20181122075321.GJ3369@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Nov 15, 2018 at 05:33:26PM +0900, Masahiko Sawada wrote:
> Yeah, I also agree with 'reply_time'. But please also note that we had
> the discussion when there is not the similar system catalogs and
> fields. Now that we have them it might be worth to consider to follow
> the existing name for consistency.

The fields in pg_stat_wal_receiver are named after their respective
fields. Now if you look at the fields from pg_stat_replication, you
have those from the standby:
sent_lsn => Last write-ahead log location sent on this connection
write_lsn => Last write-ahead log location written to disk by this
standby server
flush_lsn => Last write-ahead log location flushed to disk by
this standby server
replay_lsn => Last write-ahead log location replayed into the
database on this standby server

So to keep the brand consistent, reply_time looks like the best choice
as Sawada-san suggests?
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Adrien NAYRAT 2018-11-22 08:20:19 Re: performance statistics monitoring without spamming logs
Previous Message David Rowley 2018-11-22 07:41:10 Re: Tid scan improvements