Re: Adding locks statistics

From: Greg Sabino Mullane <htamfids(at)gmail(dot)com>
To: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Adding locks statistics
Date: 2025-08-11 17:54:38
Message-ID: CAKAnmm+USTr5MeKuyrAvbCjHqbSFbZ+czJsV7fPYt9nECQkf-A@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Great idea. +1. Here is a quick overall review to get things started.

Meta:
patch did not apply via "git apply". Also has carriage returns (e.g. DOS
file), and some errant whitespace. Seems to pass pgindent, though.

Name:
I think the name would read better as pg_stat_locks, especially as it
returns multiple rows.

Docs: seem good. Needs a section on how to reset via
SELECT pg_stat_reset_shared('lock');
Also plural better here ('locks')

Code:

+ * Copyright (c) 2021-2025, PostgreSQL Global Development Group

If a new file, we can simply say 2025?

+ LWLock locks[LOCKTAG_LAST_TYPE + 1];
+ PgStat_Lock stats;

Adding a lock to the system that counts locks! :) (just found amusing, not
a comment)

-#define PGSTAT_KIND_SLRU 11
-#define PGSTAT_KIND_WAL 12
+#define PGSTAT_KIND_LOCK 11
+#define PGSTAT_KIND_SLRU 12
+#define PGSTAT_KIND_WAL 13

Why not just add LOCK as #13?

What about the overhead of maintaining this system? I know it's overall
very lightweight, but from my testing, the relation locktype in particular
is very, very busy. Busier than I realized until I saw it in this useful
view!

Cheers,
Greg

--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2025-08-11 17:55:57 Re: Extension security improvement: Add support for extensions with an owned schema
Previous Message Doruk Yilmaz 2025-08-11 17:11:34 Re: [Patch] add new parameter to pg_replication_origin_session_setup