Stability of queryid in minor versions

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Stability of queryid in minor versions
Date: 2024-04-14 23:20:16
Message-ID: CAApHDvpYGE6h0cD9UO-eHySPynPj1L3J=HxT+A7Ud8_Yo6AuzA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I was recently asked internally about the stability guarantees we
offer for queryid. My answer consisted of:

1. We cannot change Node enums in minor versions
2. We're *unlikely* to add fields to Node types in minor versions, and
if we did we'd likely be leaving them out of the jumble calc, plus it
seems highly unlikely any new field we wedged into the padding would
relate at all to the parsed query.

While answering, I checked what our documentation says. It does not
seem to offer much in the way of what is guaranteed between minor
versions.

In [1] I see:

"As a rule of thumb, queryid values can be assumed to be stable and
comparable only so long as the underlying server version"

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.

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've drafted a patch which I think improves things, but it probably
needs more work and opinions.

David

[1] https://www.postgresql.org/docs/current/pgstatstatements.html

Attachment Content-Type Size
doc_clarify_queryid_stability.patch text/plain 973 bytes

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2024-04-14 23:38:09 Re: Fix out-of-bounds in the function GetCommandTagName
Previous Message Ranier Vilela 2024-04-14 23:17:35 Fix out-of-bounds in the function GetCommandTagName