Re: Stability of queryid in minor versions - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Stability of queryid in minor versions
Date
Msg-id CAH2-WznovfviiQCrDAGLN6VGqFd3wEcze-AGDzAeEd+2FB6TEg@mail.gmail.com
Whole thread Raw
In response to [MASSMAIL]Stability of queryid in minor versions  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: Stability of queryid in minor versions  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers
On Sun, Apr 14, 2024 at 7:20 PM David Rowley <dgrowleyml@gmail.com> wrote:
> It's the "underlying server version" that I think needs some
> clarification. It's unclear if the minor version must match or just
> the major version number. The preceding paragraph does mention:
>
> "Furthermore, it is not safe to assume that queryid will be stable
> across major versions of PostgreSQL."
>
> but not stable across *major* versions does *not* mean stable across
> *minor* versions. The reader is just left guessing if that's true.

Technically we don't promise that WAL records won't change in minor
versions. In fact, the docs specifically state that the format of any
WAL record might change, and that users should upgrade standbys first
on general principle (though I imagine few do). We try hard to avoid
changing the format of WAL records in point releases, of course, but
strictly speaking there is no guarantee. This situation seems similar
(though much lower stakes) to me. Query normalization isn't perfect --
there's a trade-off.

> Maybe the paragraph starting with "Consumers of" can detail the
> reasons queryid might be unstable and the following paragraph can
> describe the scenario for when the queryid can generally assumed to be
> stable.

I think that it would be reasonable to say that we strive to not break
the format in point releases. Fundamentally, if pg_stat_statements
sees a hard queryid format change (e.g. due to a major version
upgrade), then pg_stat_statements throws away the accumulated query
stats without being asked to.

--
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: [MASSMAIL]meson and pg_config --libs/--ldflags_ex
Next
From: Tom Lane
Date:
Subject: Re: Fix out-of-bounds in the function GetCommandTagName