Re: Add connection active, idle time to pg_stat_activity

From: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
To: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
Cc: Rafia Sabih <rafia(dot)pghackers(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Add connection active, idle time to pg_stat_activity
Date: 2021-11-29 06:02:44
Message-ID: CAFiTN-sJnNn0jy8yWeb4m8uBLOXQRogMCKK9CzQuhkUx3uZHng@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Nov 27, 2021 at 8:00 AM Bharath Rupireddy
<bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
>
> On Tue, Nov 16, 2021 at 5:06 PM Rafia Sabih <rafia(dot)pghackers(at)gmail(dot)com> wrote:
> > Got it.
> > Updated
>
> Thanks for the patch. +1 for adding the idle/idle_in_txn_time/active
> time. I believe these are the total times a backend in its lifetime
> accumulates. For instance, if a backend runs 100 txns, then these new
> columns show the total time that the backend spent during these 100
> txns, right?
>
> Few comments on the patch:
>
> 1) Patch is missing a commit message. It is good to have a commit
> message describing the high-level of the feature.
> 2) This patch needs to bump the catalog version, at the end of the
> commit message, we usually keep a note "Bump the catalog version".
> 3) It looks like the documentation is missing [1], for the new columns.
> 4) When will these backend variables be reset? Is it at the backend
> startup? Or some other? If these variables are reset only at the
> backend startup and do they keep growing during the entire life of the
> backend process? If yes, what happens for a long running backend/user
> session, don't they get overflowed?

This is a 64-bit variable so I am not sure do we really need to worry
about overflow? I mean if we are storing microseconds then also this
will be able to last for ~300,000 years no?

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2021-11-29 06:07:50 Re: Skipping logical replication transactions on subscriber side
Previous Message Yugo NAGATA 2021-11-29 05:58:31 Re: Commitfest 2021-11 Patch Triage - Part 1