> 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)
