> That's very strange. I'm pretty sure that I tried since the earlier approach I
> mentioned using doing it in CreateCachedPlan() had that exact problem.
>
> Also, src/test/recovery/t/027_stream_regress.pl does run the full regression
> tests with pg_stat_statements enabled, and it doesn't fail.
>
> I'm not sure what is different in your case.
the regression tests succeed because by the time the multi-statement command
is executed, the queries involved have already been tracked by
pg_stat_statements,
so they don't need to get stored again, and no reason to go through
generate_normalize_query. In this case, SELECT $1 is already tracked.
To repro the crash, just reset pg_stat_statements prior.
```
diff --git a/src/test/regress/sql/prepare.sql b/src/test/regress/sql/prepare.sql
index 0e7fe44725e..51421357f26 100644
--- a/src/test/regress/sql/prepare.sql
+++ b/src/test/regress/sql/prepare.sql
@@ -4,6 +4,9 @@
SELECT name, statement, parameter_types, result_types FROM
pg_prepared_statements;
+CREATE EXTENSION pg_stat_statements;
+SELECT pg_stat_statements_reset();
+
SELECT 'bingo'\; PREPARE q1 AS SELECT 1 AS a \; SELECT 42;
EXECUTE q1;
```
For this test, we should either reset statements before or construct a
statement for the test that has not been tracked. We can maybe
do that with a query against a newly created table in prepare.sql.
I like the latter more.
--
Sami Imseih
Amazon Web Services (AWS)
