On Mon, 15 Apr 2024 at 11:47, Peter Geoghegan <pg@bowt.ie> wrote:
>
> 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.
set compute_query_id = 'on';
explain (costs off, verbose) select oid from pg_class;
QUERY PLAN
-----------------------------------------------------------------
Index Only Scan using pg_class_oid_index on pg_catalog.pg_class
Output: oid
Query Identifier: -8748805461085747951
(3 rows)
As far as I understand query ID; it's based on the parse nodes and
values in the system catalogue tables and is calculated on the local
server. Computed values are susceptible to variations in hash values
calculated by different CPU architectures.
Where does WAL fit into this? And why would a WAL format change the
computed value?
David