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
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() |