Doc: document cases where queryid is stable

The documents were clear that queryid should not be assumed to be stable
between major versions but said nothing about minor versions and left
the reader to guess if that was implied by the mention of the
instability of queryid between major versions.

Here we give minor versions an explicit mention to indicate queryid can
generally be assumed stable between minor versions.

Reviewed-by: Michael Paquier
Discussion: https://postgr.es/m/CAApHDvpYGE6h0cD9UO-eHySPynPj1L3J%3DHxT%2BA7Ud8_Yo6AuzA%40mail.gmail.com
Backpatch-through: 12
This commit is contained in:
David Rowley 2024-04-20 13:54:46 +12:00
parent af715a6f39
commit 38daca854a
1 changed files with 15 additions and 9 deletions

View File

@ -554,15 +554,21 @@
</para>
<para>
As a rule of thumb, <structfield>queryid</structfield> values can be assumed to be
stable and comparable only so long as the underlying server version and
catalog metadata details stay exactly the same. Two servers
participating in replication based on physical WAL replay can be expected
to have identical <structfield>queryid</structfield> values for the same query.
However, logical replication schemes do not promise to keep replicas
identical in all relevant details, so <structfield>queryid</structfield> will
not be a useful identifier for accumulating costs across a set of logical
replicas. If in doubt, direct testing is recommended.
Two servers participating in replication based on physical WAL replay can
be expected to have identical <structfield>queryid</structfield> values for
the same query. However, logical replication schemes do not promise to
keep replicas identical in all relevant details, so
<structfield>queryid</structfield> will not be a useful identifier for
accumulating costs across a set of logical replicas.
If in doubt, direct testing is recommended.
</para>
<para>
Generally, it can be assumed that <structfield>queryid</structfield> values
are stable between minor version releases of <productname>PostgreSQL</productname>,
providing that instances are running on the same machine architecture and
the catalog metadata details match. Compatibility will only be broken
between minor versions as a last resort.
</para>
<para>