Re: Stack-based tracking of per-node WAL/buffer usage

Zsolt Parragi <zsolt.parragi@percona.com>

From: Zsolt Parragi <zsolt.parragi@percona.com>
To: Lukas Fittl <lukas@fittl.com>
Cc: Andres Freund <andres@anarazel.de>, Heikki Linnakangas <hlinnaka@iki.fi>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Tomas Vondra <tomas@vondra.me>, Peter Smith <smithpb2250@gmail.com>
Date: 2026-04-06T22:46:46Z
Lists: pgsql-hackers
I couldn't find any issues with v15, all comments are stylistic/minor,
except maybe the first one.

+ /* Abort handling: link in parent QueryInstrumentation's unfinalized list */
+ dlist_node unfinalized_entry;

Is it okay to store a pointer in shared memory, even if it seems to be
always NULL there?

 #ifndef INSTRUMENT_NODE_H
 #define INSTRUMENT_NODE_H

+
+#include "executor/tuptable.h"
+#include "nodes/execnodes.h"
+

Is it okay to incude files in the middle of the file, is there a good
reason why these can't be at the top of the file?

+ * Recurse into children first (bottom-up accumulation), and accummulate
+ * to this nodes instrumentation as the parent context.

Two typos (accumulate / this node's)

 #define RELEASE_PRIO_FILES 600
 #define RELEASE_PRIO_WAITEVENTSETS 700
+#define RELEASE_PRIO_INSTRUMENTATION 800

This is mainly a generic observation, not strictly related to this
patch, but this list could use some explanation which of these
priorities are actually required by dependencies, and which are just
"put the new entry at the end of the list".



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. instrumentation: Allocate query level instrumentation in ExecutorStart

  2. instrumentation: Move ExecProcNodeInstr to allow inlining

  3. instrumentation: Separate per-node logic from other uses

  4. instrumentation: Separate trigger logic from other uses

  5. instrumentation: Rename INSTR_TIME_LT macro to INSTR_TIME_GT

  6. instrumentation: Keep time fields as instrtime, convert in callers