On Mon, Jan 18, 2021 at 5:11 PM Laurenz Albe wrote:
>
> On Sun, 2021-01-17 at 14:07 +0100, Magnus Hagander wrote:
> > I have applied this version, with some minor changes:
> >
> > * I renamed the n__time members in the struct to just
> > total__time. The n_ indicates "number of" and is thus wrong
On Sun, 2021-01-17 at 14:07 +0100, Magnus Hagander wrote:
> I have applied this version, with some minor changes:
>
> * I renamed the n__time members in the struct to just
> total__time. The n_ indicates "number of" and is thus wrong for
> time parameters.
Right.
> * Some very minor wording chan
On Fri, Jan 8, 2021 at 10:34 AM Laurenz Albe wrote:
>
> On Fri, 2021-01-08 at 12:00 +0900, Masahiro Ikeda wrote:
> > 2. monitoring.sgml
> >
> > > > IIUC, "active_time" includes the time executes a fast-path function
> > > > and
> > > > "idle in transaction" includes "idle in transaction(aborted)"
On 2021-01-08 18:34, Laurenz Albe wrote:
On Fri, 2021-01-08 at 12:00 +0900, Masahiro Ikeda wrote:
2. monitoring.sgml
> > IIUC, "active_time" includes the time executes a fast-path function
> > and
> > "idle in transaction" includes "idle in transaction(aborted)" time.
> > Why don't you referenc
ere are some functions that do it like this:
int32 result;
result = 0;
for (...)
{
if (...)
result++;
}
PG_RETURN_INT32(result);
Again, it is a matter of taste, and I didn't detect a clear pattern
in the existing code that I feel I should
On 2021-01-08 00:47, Laurenz Albe wrote:
On Fri, 2020-12-25 at 20:28 +0900, Masahiro Ikeda wrote:
As a user, I want this feature to know whether
clients' session activities are as expected.
I have some comments about the patch.
Thanks you for the thorough review!
Thanks for updating the pat
y one space.
>
> // }Pgstat_MsgConn;
Yes, I messed that up during the pgindent run. Fixed.
Patch version 11 is attached.
Yours,
Laurenz Albe
From 324847353f5d9e5b2899dd93d43fb345df1dcdb8 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Thu, 7 Jan 2021 16:33:45 +0100
Subject: [PATCH
On Fri, 2020-12-25 at 20:28 +0900, Masahiro Ikeda wrote:
> As a user, I want this feature to know whether
> clients' session activities are as expected.
>
> I have some comments about the patch.
>
> 1. pg_proc.dat
>
> The unit of "session time" and so on says "in seconds".
> But, is "in millisec
Hi,
As a user, I want this feature to know whether
clients' session activities are as expected.
I have some comments about the patch.
1. pg_proc.dat
The unit of "session time" and so on says "in seconds".
But, is "in milliseconds" right?
2. monitoring.sgml
IIUC, "active_time" includes the
TCH] Add session statistics to pg_stat_database
If "track_counts" is active, track the following per database:
- total number of connections
- number of sessions that ended by loss of network connection,
fatal errors and operator intervention
- total time spent in database sessions
- tot
n the same place, seems this should be
> SessionEndType.
True. I have renamed the type.
Attached is patch version 9.
Added goodie: I ran pgindent on it.
Yours,
Laurenz Albe
From b40e34141c80ff59c0005f430bd8c273918eb7bb Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Tue, 15 Dec 2020 13:46:4
On Sat, Dec 5, 2020 at 1:04 PM Laurenz Albe
wrote:
> On Fri, 2020-12-04 at 16:55 +0100, I wrote:
> > > > Basically, that would change pgStatSessionDisconnectedNormally into
> instead being an
> > > > enum of reasons, which could be normal disconnect, abnormal
> disconnect and admin.
> > > > And w
f", "sessions_fatal" and
"sessions_killed", but I am not wedded to these bike shed colors.
Yours,
Laurenz Albe
From 96c4aaa71ceff3ef83004780ac6dc3f5059302bb Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Sat, 5 Dec 2020 12:58:46 +0100
Subject: [PATCH] Add session statisti
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 t
dmin" 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 th
On Fri, Nov 20, 2020 at 3:41 PM Laurenz Albe
wrote:
> On Tue, 2020-11-17 at 17:33 +0100, Magnus Hagander wrote:
> > I've taken a look as well, and here are a few short notes:
>
> Much appreciated!
>
Sorry about the delay in getting back to you on this one. FYI, while the
patch has been bumped to
for the stats
collector
to tell the difference between a start after a backend crash and - say -
starting from
a base backup.
Patch v6 attached.
I think that that would be material for another patch, and I don't think it
should go
to "pg_stat_database", because a) it might be har
On Tue, Nov 17, 2020 at 4:22 PM Laurenz Albe
wrote:
> On Fri, 2020-10-16 at 16:24 +0500, Ahsan Hadi wrote:
> > I have applied the latest patch on master, all the regression test cases
> are passing
> > and the implemented functionality is also looking fine. The point that
> I raised about
> > i
On Fri, 2020-10-16 at 16:24 +0500, Ahsan Hadi wrote:
> I have applied the latest patch on master, all the regression test cases are
> passing
> and the implemented functionality is also looking fine. The point that I
> raised about
> idle connection not included is also addressed.
If you think
‐‐‐ Original Message ‐‐‐
On Thursday, November 12, 2020 9:31 AM, Laurenz Albe
wrote:
> I wrote:
>
> > On Tue, 2020-11-10 at 15:03 +, Georgios Kokolatos wrote:
> >
> > > I noticed that the cfbot fails for this patch.
> > > For this, I am setting the status to: 'Waiting on Author'.
I wrote:
> On Tue, 2020-11-10 at 15:03 +, Georgios Kokolatos wrote:
> > I noticed that the cfbot fails for this patch.
> >
> > For this, I am setting the status to: 'Waiting on Author'.
>
> Thanks for noticing, it was only the documentation build.
>
> Version 5 attached, status changed back
"waiting for review".
Yours,
Laurenz Albe
From afc37856c12fd0a85587c638fca291a0b5652d9b Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Wed, 11 Nov 2020 20:14:28 +0100
Subject: [PATCH] Add session statistics to pg_stat_database
If "track_counts" is active, track the fo
Hi,
I noticed that the cfbot fails for this patch.
For this, I am setting the status to: 'Waiting on Author'.
Cheers,
//Georgios
The new status of this patch is: Waiting on Author
Hi Laurenz,
I have applied the latest patch on master, all the regression test cases
are passing and the implemented functionality is also looking fine. The
point that I raised about idle connection not included is also addressed.
thanks,
Ahsan
On Wed, Oct 14, 2020 at 2:28 PM Laurenz Albe
wrote
lly copied from neighboring functions,
which then should also be changed like this, but that is outside
the scope of this patch.
Attached is v4 of the patch.
Yours,
Laurenz Albe
From 9e8bf3efd984306c73243736d0b4a4023cdd5f3a Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Wed, 14 Oct 2020 11:08:2
On Tue, Oct 13, 2020 at 01:44:41PM +0200, Laurenz Albe wrote:
> Attached is v3 with improvements.
+
+ Time spent in database sessions in this database, in milliseconds.
+
Should say "Total time spent *by* DB sessions..." ?
I think these counters are only accurate as of the last
attempts to connect to a non-existing database?
I agree that this is interesting information, but I don't think it
belongs into this patch.
> By the way, could you rebase the patch since the latest patches
> failed to be applied to the master branch?
Yes, the patch has bit-rotted.
Atta
On 2020-09-05 00:50, Laurenz Albe wrote:
I have changed the code so that connections are counted immediately.
Attached is a new version.
Thanks for making a patch.
I'm interested in this feature.
I think to add the number of login failures is good for security.
Although we can see the event fr
On Tue, Sep 29, 2020 at 2:44 AM Laurenz Albe wrote:
> > * Are we trying to capture ONLY client initiated disconnects in
> > m_aborted (we are not handling other disconnects by not accounting for
> > EOF..like if psql was killed)? If yes, why?
>
> I thought it was interesting to know how many dat
On Thu, 2020-09-24 at 14:38 -0700, Soumyadeep Chakraborty wrote:
> Thanks for submitting this! Please find my feedback below.
Thanks for the thorough review.
Before I update the patch, I have a few comments and questions.
> * Are we trying to capture ONLY client initiated disconnects in
> m_abor
Hello Laurenz,
Thanks for submitting this! Please find my feedback below.
* Are we trying to capture ONLY client initiated disconnects in
m_aborted (we are not handling other disconnects by not accounting for
EOF..like if psql was killed)? If yes, why?
* pgstat_send_connstats(): How about renami
ediately.
I have changed the code so that connections are counted immediately.
Attached is a new version.
Yours,
Laurenz Albe
From 6d9bfbd682a9f4723f030fdc461f731175f55f44 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Fri, 4 Sep 2020 17:30:24 +0200
Subject: [PATCH] Add session statistics to pg_s
On Thu, 2020-07-23 at 18:16 +0500, Ahsan Hadi wrote:
> On Wed, Jul 8, 2020 at 4:17 PM Laurenz Albe wrote:
> > Here is a patch that adds the following to pg_stat_database:
> > - number of connections
>
> Is it expected behaviour to not count idle connections? The connection is
> included after it
On Wed, Jul 8, 2020 at 4:17 PM Laurenz Albe
wrote:
> Here is a patch that adds the following to pg_stat_database:
> - number of connections
>
Is it expected behaviour to not count idle connections? The connection is
included after it is aborted but not while it was idle.
> - number of sessions
statistics to pg_stat_database
If "track_counts" is active, track the following per database:
- number of connections
- number of sessions that were not disconnected regularly
- total time spent in database sessions
- total time spent executing queries
- total idle in transaction time
This is
35 matches
Mail list logo
