Re: Add session statistics to pg_stat_database - Mailing list pgsql-hackers

From Laurenz Albe
Subject Re: Add session statistics to pg_stat_database
Date
Msg-id 6fac65dcf175175f95d5fb2aeae731b70bec0a58.camel@cybertec.at
Whole thread Raw
In response to Re: Add session statistics to pg_stat_database  (Laurenz Albe <laurenz.albe@cybertec.at>)
Responses Re: Add session statistics to pg_stat_database
List pgsql-hackers
On Thu, 2020-12-03 at 13:22 +0100, Laurenz Albe wrote:
> > Basically, that would change pgStatSessionDisconnectedNormally into instead being an
> > enum of reasons, which could be normal disconnect, abnormal disconnect and admin.
> > And we'd track all those three as separate numbers in the stats file, meaning we could
> > then calculate the crash by subtracting all three from the total number of sessions?
> 
> I think at least "closed by admin" might be interesting; I'll have a look.
> I don't think we have to specifically count "closed by normal disconnect", because
> that should be the rule and could be more or less deduced from the other numbers
> (with the uncertainty mentioned above).
> 
> > (Let me know if you think the idea could work and would prefer it if I worked up a
> > complete suggestion based on it rather than just spitting ideas)
> 
> Thanks for the offer, and I'll get back to it if I get stuck.

Ok, I could use a pointer.

I am considering the cases

1) client just went away (currently "aborted")
2) death by FATAL error
3) killed by the administrator (or shutdown)

What is a good place in the code to tell 2) or 3)
so that I can set the state accordingly?

Yours,
Laurenz Albe




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] [PATCH] Generic type subscripting
Next
From: "Joel Jacobson"
Date:
Subject: [PATCH] Add support for leading/trailing bytea trim()ing