Re: Skip unregistered custom kinds on stats load

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Sami Imseih <samimseih(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Skip unregistered custom kinds on stats load
Date: 2025-10-20 23:23:45
Message-ID: aPbEgXsiDNUrs8Ji@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Oct 20, 2025 at 01:39:37PM -0500, Sami Imseih wrote:
> I think this can be better handled by tracking the lengths of the
> kinds in the pgstat.stat file when saving, and re-reading the lengths
> on startup. This would allow skipping past any unrecognized custom
> data. We need to save the lengths since we have no way to know how
> much to skip when re-reading. The data can be saved at the start of
> the file, after the FORMAT, so the extra space required is minimal.

+ /* Write the lengths of all stats kinds */
+ for (PgStat_Kind kind = PGSTAT_KIND_MIN; kind <= PGSTAT_KIND_MAX; kind++)
+ {
+ size_t kind_len = 0;
+
+ const PgStat_KindInfo *kind_info = pgstat_get_kind_info(kind);
+
+ if (kind_info)
+ kind_len = pgstat_get_entry_len(kind);
+
+ kind_lengths[kind - 1] = kind_len;
+ write_chunk_s(fpout, &kind_len);
+ }

The fun does not stop there. This also means that the data tracked in
the file becomes incorrect if a server tries to reuse the same ID
across two restarts with a different kind attached to them. The point
is that giving up is kind of always the safest bet and acts as a
sanity measure, giving priority to the availability of the server.

Perhaps we should document better all these properties, meaning that
keeping a file compatible requires the stats kind to be loaded, even
if it means replacing a past one with an "idle" kind, that could
discard past stats that are not supported anymore so as the same stats
kind can be reused in the future (that could be also settable as a GUC
defined by the library loaded with shared_preload_libraries from where
the custom stats kind originates).
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2025-10-20 23:31:05 Re: Optimize SnapBuildPurgeOlderTxn: use in-place compaction instead of temporary array
Previous Message Michael Paquier 2025-10-20 23:11:42 Re: [PATCH] Fix POSIX compliance in pgwin32_unsetenv()