Hello, hackers.
I've attached the fifth version of the patch that incorporates suggestions
from Andrei.
The version runs successfully on top of 8fcd80258bcf43dab93d877
> Right now it is not clear for me if we can get resource statistics from
> those backends while those are listed in the pg_stat
Hi Sergei,
> I still would like to maintaint the focus on committing the "idle in
transactions" part of pg_stat_session first.
Agreed.
I've done a review of version 0004. This version is applied successful
over ce571434ae7, installcheck passed. The behavior of pg_stat_session
view and correspond
Hi again,
> It looks like we can check increments in all fields playing with
transactions in tests.
I've added such tests.
Regards,
Sergey
From 66ac1efe5424aa1385744a60047ffd44d42dd244 Mon Sep 17 00:00:00 2001
From: Sergey Dudoladov
Date: Thu, 1 Feb 2024 16:11:36 +0100
Subject: [PATCH] Add pg_s
Hi all,
@Andrei Zubkov
I've modify the patch to address most of your comments.
> I have a thought about other possible improvements fitting to this patch.
> I think pg_stat_session view is able to add one more dimension of
monitoring - a dimension of sessions
I would like to remind here about t
On Wed, 25 Oct 2023 at 19:06, Andrei Zubkov wrote:
>
> Hi Aleksander,
>
> On Wed, 2023-10-25 at 16:17 +0300, Aleksander Alekseev wrote:
> > On top of that not sure if I see the patch on the November commitfest
> > [1]. Please make sure it's there so that cfbot will check the patch.
>
> Yes, this p
Hi,
> On Wed, 2023-10-25 at 16:17 +0300, Aleksander Alekseev wrote:
> > On top of that not sure if I see the patch on the November commitfest
> > [1]. Please make sure it's there so that cfbot will check the patch.
>
> Yes, this patch is listed on the November commitfest. cfbot says rebase
> neede
Hi Aleksander,
On Wed, 2023-10-25 at 16:17 +0300, Aleksander Alekseev wrote:
> On top of that not sure if I see the patch on the November commitfest
> [1]. Please make sure it's there so that cfbot will check the patch.
Yes, this patch is listed on the November commitfest. cfbot says rebase
neede
Hi,
> I've done a review of this patch. I found the patch idea very useful,
> thank you for the patch. I've noted something observing this patch:
> 1. Patch can't be applied on the current master. My review is based on
>application of this patch over ac68323a878
On top of that not sure if I s
Hi Sergey,
I've done a review of this patch. I found the patch idea very useful,
thank you for the patch. I've noted something observing this patch:
1. Patch can't be applied on the current master. My review is based on
application of this patch over ac68323a878
2. Being applied over ac68323a87
Hello hackers,
Andrey and Nik, thank you for selecting this patch for review in
Postgres Hacking 101: I've modified the patch based both on your email
and the video.
1. Session statistics is now collected only for client backends. PG
internal processes like wal sender seem to stop sending statist
On Wed, Feb 1, 2023 at 12:46 PM Sergey Dudoladov
wrote:
>
> I've sketched the first version of a patch to add pg_stat_session.
> Please review this early version.
Hi Sergey!
I've taken a look into the patch and got some notes.
1. It is hard to understand what fastpath backend state is. What do
f
Hello hackers,
I've sketched the first version of a patch to add pg_stat_session.
Please review this early version.
Regards,
Sergey.
From 31f781ecd69fc42aaadd9bcdbebaf8f72449946c Mon Sep 17 00:00:00 2001
From: Sergey Dudoladov
Date: Tue, 22 Nov 2022 09:23:32 +0100
Subject: [PATCH] Add pg_stat_se
On Tue, Nov 8, 2022 at 7:37 PM Andres Freund wrote:
> On 2022-11-08 19:25:27 -0700, David G. Johnston wrote:
> > Actually two, because I also suggest that not only is the duration
> recorded,
> > but a counter be incremented each time a given state becomes the
> currently
> > active state. Seems
On 2022-11-08 19:25:27 -0700, David G. Johnston wrote:
> Actually two, because I also suggest that not only is the duration recorded,
> but a counter be incremented each time a given state becomes the currently
> active state. Seems like having access to a divisor of some form may be
> useful.
Wh
On Tue, Nov 8, 2022 at 6:56 PM Andres Freund wrote:
>
> Separately from that, I'm a bit worried about starting to add accumulative
> counters to pg_stat_activity. It's already gotten hard to use interactively
> due to the number of columns - and why stop with the columns you suggest?
> Why
> not
Hi,
On 2022-07-21 18:22:51 +0200, Sergey Dudoladov wrote:
> From b5298301a3f5223bd78c519ddcddbd1bec9cf000 Mon Sep 17 00:00:00 2001
> From: Sergey Dudoladov
> Date: Wed, 20 Apr 2022 23:47:37 +0200
> Subject: [PATCH] pg_stat_activity: add 'total_active_time' and
> 'total_idle_in_transaction_time'
Hello hackers,
Is there anything we can do to facilitate merging of this patch ?
It has been in the "ready-for-commiter" state for 3 commitfests in a row now.
We would appreciate if the patch makes it to version 16: the need to
monitor idle-in-transaction connections is very real for us.
Regards
Hi hackers,
All in all the patch seems to be in good shape.
> This is consistent with the current documentation:
>
> > Each individual server process transmits new statistical counts to the
> > collector just before going idle; so a query or transaction still in
> > progress does not affect the
Hi Sergey,
> @Aleksander Alekseev thanks for reporting the issue. I have altered
> the patch to respect the behavior of pg_stat_activity, specifically
> [1]
>
> > Another important point is that when a server process is asked to
display any of these statistics,
> > it first fetches the most recent
Hello,
I have addressed the reviews.
@Aleksander Alekseev thanks for reporting the issue. I have altered
the patch to respect the behavior of pg_stat_activity, specifically
[1]
> Another important point is that when a server process is asked to display any
> of these statistics,
> it first fetc
Rafia, Sergey,
+1 for adding the total_active_time and total_idle_in_transaction_time
to pg_stat_activity.
I reviewed the patch and here are some comments.
+
+ total_active_time double
precision
+
+
+ Time in milliseconds this backend spent in
active and
+
Hi again,
> 57033 (master) =# select * from pg_stat_activity where pid = 57033;
> ...
> total_active_time | 2514.635
> total_idle_in_transaction_time | 2314.703
>
> 57033 (master) =# COMMIT;
> 57033 (master) =# select * from pg_stat_activity where pid = 57033;
> ...
> total_active_tim
Rafia, Sergey,
Many thanks for working on this!
> I have incorporated most of the suggestions into the patch. I have also
> rebased and tested the patch on top of the current master
I noticed that this patch is marked as "Needs Review" and decided to
take a look.
I believe there is a bug in th
Hello,
thanks for the helpful review. I have incorporated most of the
suggestions into the patch. I have also rebased and tested the patch
on top of the current master (2cd2569c72b89200).
> + int64 active_time_diff = 0;
> + int64 transaction_idle_time_diff = 0;
>
>
Hello,
I've updated the patch in preparation for the upcoming commitfest.
Regards,
Sergey.
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 4549c2560e..cf00685c96 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -979,6 +979,26 @@ postgr
Hi,
On 2022-02-04 10:58:24 +0100, Sergey Dudoladov wrote:
> Thank you for the contribution. I included both of your diffs with
> minor changes.
This currently doesn't apply: http://cfbot.cputube.org/patch_37_3405.log
Could you rebase? Marking as waiting on author for now.
- Andres
Hi,
> > Could you please elaborate on this idea ?
> > So we have pgStatActiveTime and pgStatIdleInTransactionTime ultimately
> > used to report respective metrics in pg_stat_database.
> > Now beentry's st_total_active_time / st_total_transaction_idle_time
> > duplicates this info, so one may get r
At Mon, 31 Jan 2022 15:11:56 +0100, Sergey Dudoladov
wrote in
> > > if (beentry->st_state == STATE_RUNNING ||
> > > beentry->st_state == STATE_FASTPATH)
> > > - pgstat_count_conn_active_time((PgStat_Counter) secs
> > > * 100 + usecs);
Hi,
Thank you for the reviews.
> > The write operation to beentry needs to be enclosed by
> > PGSTAT_BEGIN/END_WRITE_ACTIVITY(). In that perspective, it would be
> > better to move that writes to the PGSTAT_WRITE_ACTIVITY section just
> > below.
I have fixed it in the new version.
> >
At Fri, 28 Jan 2022 14:36:31 +0900 (JST), Kyotaro Horiguchi
wrote in
> Hi.
>
> At Thu, 27 Jan 2022 20:36:56 +0800, Julien Rouhaud wrote
> in
> > On Thu, Jan 27, 2022 at 11:43:26AM +0100, Sergey Dudoladov wrote:
> > >
> > > Per agreement with Rafia I have reworked the patch in the past days.
At Mon, 29 Nov 2021 20:34:14 +0530, Kuntal Ghosh
wrote in
> active_time. But, I'm wondering why you need to distinguish between
> idle and idle in transactions - what's the usage? Either the backend
> is doing some work or it sits idle. Another useful information would
I believe many people suf
Hi.
At Thu, 27 Jan 2022 20:36:56 +0800, Julien Rouhaud wrote in
> On Thu, Jan 27, 2022 at 11:43:26AM +0100, Sergey Dudoladov wrote:
> >
> > Per agreement with Rafia I have reworked the patch in the past days.
> > The new version 6 is now ready for review.
>
> Great, thanks a lot Sergey!
>
> Th
Hi,
On Thu, Jan 27, 2022 at 11:43:26AM +0100, Sergey Dudoladov wrote:
>
> Per agreement with Rafia I have reworked the patch in the past days.
> The new version 6 is now ready for review.
Great, thanks a lot Sergey!
The cfbot is happy with this new version:
https://cirrus-ci.com/github/postgres
Hello,
> Without update in the next few
> days this patch will be closed as Returned with Feedback,
Thank you for the reminder, Julien.
Per agreement with Rafia I have reworked the patch in the past days.
The new version 6 is now ready for review.
Regards,
Sergey Dudoladov
diff --git a/doc/sr
Hi,
On Wed, Jan 12, 2022 at 02:16:35PM +0800, Julien Rouhaud wrote:
>
> On Mon, Nov 29, 2021 at 11:04 PM Kuntal Ghosh
> wrote:
> >
> > You also need to update the documentation.
>
> You also need to update rules.sql: https://cirrus-ci.com/task/6145265819189248
There has been multiple comments
Hi,
On Mon, Nov 29, 2021 at 11:04 PM Kuntal Ghosh
wrote:
>
> You also need to update the documentation.
You also need to update rules.sql: https://cirrus-ci.com/task/6145265819189248
On Fri, Oct 22, 2021 at 1:53 PM Rafia Sabih wrote:
> To provide this information I was digging into how the statistics
> collector is working and found out there is already information like
> total time that a connection is active as well as idle computed in
> pgstat_report_activity[1]. Ideally, t
On Sat, Nov 27, 2021 at 8:00 AM Bharath Rupireddy
wrote:
>
> On Tue, Nov 16, 2021 at 5:06 PM Rafia Sabih 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
On Tue, Nov 16, 2021 at 5:06 PM Rafia Sabih 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 to
On Tue, Nov 16, 2021 at 5:06 PM Rafia Sabih wrote:
> > I think this change is wrong, basically, "tsmsg->m_idle_in_xact_time"
> > is used for counting the database level idle in transaction count, you
> > can check "pg_stat_get_db_idle_in_transaction_time" function for that.
> > So "pgStatTransact
On Mon, 15 Nov 2021 at 12:40, Dilip Kumar wrote:
>
> On Mon, Nov 15, 2021 at 4:46 PM Rafia Sabih wrote:
> >
> > On Mon, 15 Nov 2021 at 10:24, Dilip Kumar wrote:
> > >
> > > On Wed, Nov 10, 2021 at 1:47 PM Rafia Sabih
> > > wrote:
> > > >
> > > > > It seems that in beentry->st_idle_time, you wa
On Mon, Nov 15, 2021 at 4:46 PM Rafia Sabih wrote:
>
> On Mon, 15 Nov 2021 at 10:24, Dilip Kumar wrote:
> >
> > On Wed, Nov 10, 2021 at 1:47 PM Rafia Sabih
> > wrote:
> > >
> > > > It seems that in beentry->st_idle_time, you want to compute the
> > > > STATE_IDLE, but that state is not handled
On Mon, 15 Nov 2021 at 10:24, Dilip Kumar wrote:
>
> On Wed, Nov 10, 2021 at 1:47 PM Rafia Sabih wrote:
> >
> > > It seems that in beentry->st_idle_time, you want to compute the
> > > STATE_IDLE, but that state is not handled in the outer "if", that
> > > means whenever it comes out of the
> > >
On Wed, Nov 10, 2021 at 1:47 PM Rafia Sabih wrote:
>
> > It seems that in beentry->st_idle_time, you want to compute the
> > STATE_IDLE, but that state is not handled in the outer "if", that
> > means whenever it comes out of the
> > STATE_IDLE, it will not enter inside this if check. You can run
On Wed, 10 Nov 2021 at 09:05, Dilip Kumar wrote:
>
> On Tue, Nov 9, 2021 at 8:28 PM Rafia Sabih wrote:
> >
> > On Tue, 2 Nov 2021 at 09:00, Dilip Kumar wrote:
> > >
>
> > > About the patch, IIUC earlier all the idle time was accumulated in the
> > > "pgStatTransactionIdleTime" counter, now with
On Tue, Nov 9, 2021 at 8:28 PM Rafia Sabih wrote:
>
> On Tue, 2 Nov 2021 at 09:00, Dilip Kumar wrote:
> >
> > About the patch, IIUC earlier all the idle time was accumulated in the
> > "pgStatTransactionIdleTime" counter, now with your patch you have
> > introduced one more counter which specifi
On Tue, 2 Nov 2021 at 09:00, Dilip Kumar wrote:
>
> On Tue, Oct 26, 2021 at 5:17 PM Rafia Sabih wrote:
> >
> > >
> > > To provide this information I was digging into how the statistics
> > > collector is working and found out there is already information like
> > > total time that a connection is
On Tue, Oct 26, 2021 at 5:17 PM Rafia Sabih wrote:
>
> >
> > To provide this information I was digging into how the statistics
> > collector is working and found out there is already information like
> > total time that a connection is active as well as idle computed in
> > pgstat_report_activity[
On Fri, 22 Oct 2021 at 10:22, Rafia Sabih wrote:
>
> Hello there hackers,
>
> We at Zalando have faced some issues around long running idle
> transactions and were thinking about increasing the visibility of
> pg_stat_* views to capture them easily. What I found is that currently
> in pg_stat_acti
Hello there hackers,
We at Zalando have faced some issues around long running idle
transactions and were thinking about increasing the visibility of
pg_stat_* views to capture them easily. What I found is that currently
in pg_stat_activity there is a lot of good information about the
current state
50 matches
Mail list logo
