Re: Stability of queryid in minor versions

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Stability of queryid in minor versions
Date: 2024-04-15 00:22:03
Message-ID: CAH2-Wzn-LhtihhA_qerrq_r7ka3vu0cjkX6QQ9bKXr2r5FHn+w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Apr 14, 2024 at 8:04 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> Assuming that a query ID will be always stable across major versions
> is overconfident, I think. As Peter said, like for WAL, we may face
> cases where a slight breakage for a subset of queries could be
> justified, and pg_stat_statement would be able to cope with that by
> discarding the oldest entries in its hash tables.

If there was a minor break in compatibility, that either went
unnoticed, or was considered too minor to matter, then
pg_stat_statements would be in exactly the same position as any
external tool that uses its queryid values to accumulate query costs.
While external tools can't understand the provenance of old queryid
values, pg_stat_statements can't either.

--
Peter Geoghegan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2024-04-15 00:29:05 Re: Fix possible dereference null pointer (src/backend/replication/logical/reorderbuffer.c)
Previous Message Ranier Vilela 2024-04-15 00:12:31 Re: Fix out-of-bounds in the function GetCommandTagName