pg_stat_statements: a reset mid-query leaves an entry unnormalized forever

Hi,

Reproduced on PostgreSQL 19beta1 (pg_stat_statements 1.13) and 15.17
(1.10), Debian packages on aarch64 Linux, extension settings at default.

If pg_stat_statements_reset() lands between a statement's parse analysis
and its ExecutorEnd, the entry is recreated from the raw source text and
keeps those literals for every later execution of that query. It does not
recover on its own.

Repro:

SELECT pg_stat_statements_reset();
SELECT 1234 FROM (SELECT CASE WHEN 1=1 THEN pg_stat_statements_reset() END) s;
SELECT 5678 FROM (SELECT CASE WHEN 1=0 THEN pg_stat_statements_reset() END) s;
SELECT 9999 FROM (SELECT CASE WHEN 1=0 THEN pg_stat_statements_reset() END) s;

SELECT calls, query FROM pg_stat_statements WHERE query LIKE '%CASE%';

calls | query
-------+----------------------------------------------
3 | SELECT 1234 FROM (SELECT CASE WHEN 1=1 THEN
| pg_stat_statements_reset() END) s

Three calls under one entry, carrying the first execution's literals, down
to `1=1` though the others sent `1=0`.

Michael Renner reported the same mechanism in 2014 and the thread ended
without a code change:

https://www.postgresql.org/message-id/AEE92D38-0A85-459E-B1B8-F647FA00F3EE%40amd.co.at

I think it is worth another look because the bad text is durable rather
than a single bad sample. Tom's second suggestion there still looks like
the right fix: discard the execution stats when the entry is gone, rather
than store literals. How ExecutorEnd recognises that case with jstate
already gone is the open question, and I am happy to write a patch if the
list has a preferred direction. Either way, pgstatstatements.sgml still
does not mention that normalization is best-effort, which is where that
thread landed.

Thanks,

Gaurav Singh