Re: Resetting spilled txn statistics in pg_stat_replication - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Resetting spilled txn statistics in pg_stat_replication
Date
Msg-id CAA4eK1JHb2uwL8ytxV6e0qvTS2hD9jinXjbWDWJf7pndWDY-eA@mail.gmail.com
Whole thread Raw
In response to Re: Resetting spilled txn statistics in pg_stat_replication  (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>)
Responses RE: Resetting spilled txn statistics in pg_stat_replication
Re: Resetting spilled txn statistics in pg_stat_replication
List pgsql-hackers
On Tue, Oct 13, 2020 at 5:41 AM Masahiko Sawada
<masahiko.sawada@2ndquadrant.com> wrote:
>
> On Mon, 12 Oct 2020 at 23:45, Shinoda, Noriyoshi (PN Japan A&PS
> Delivery) <noriyoshi.shinoda@hpe.com> wrote:
> >
> >
> > > As it may have been discussed, I think the 'name' column in pg_stat_replication_slots is more consistent with the
columnname and data type matched to the pg_replication_slots catalog.
 
> > > The attached patch changes the name and data type of the 'name' column to slot_name and 'name' type,
respectively.
> >
> > It seems a good idea to me. In other system views, we use the name data type for object name. When I wrote the
firstpatch, I borrowed the code for pg_stat_slru which uses text data for the name but I think it's an oversight.
 
>
> Hmm, my above observation is wrong. All other statistics use text data
> type and internally use char[NAMEDATALEN].
>

AFAICS, we use name data-type in many other similar stats views like
pg_stat_subscription, pg_statio_all_sequences, pg_stat_user_functions,
pg_stat_all_tables. So, shouldn't we consistent with those views?

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: Wrong statistics for size of XLOG_SWITCH during pg_waldump.
Next
From: Keisuke Kuroda
Date:
Subject: Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables