Hi,
On 2022-01-14 11:11:07 +0300, Anton A. Melnikov wrote:
> This patch introduces an additional counter of wal records not related to
> the query being executed.
They're not unrelated though.
> Due to this counter pg_stat_statement finds out the number of wal records
> that are not relevant to the query and does not include them in the per
> query statistic.
-many. For read-only queries the generated WAL due to on-access pruning can be
a significant factor in performance. Removing that information makes
pg_stat_statments *less* useful.
> This removes the possibility of the error described above.
>
> There is a way to reproduce this error when patch is not applied:
> 1) start server with "shared_preload_libraries = 'pg_stat_statements'"
> string in the postgresql.conf;
> 2) replace makefile in contrib/pg_stat_statements with attached one;
> 3) replace test file contrib/pg_stat_statements/sql/pg_stat_statements.sql
> and expected results
> contrib/pg_stat_statements/expected/pg_stat_statements.out
> with shorter versions from attached files;
> 4) copy test.sh to contrib/pg_stat_statements and make sure that PGHOME
> point to your server;
> 5) cd to contrib/pg_stat_statements and execute:
> export ITER=1 && while ./start.sh || break; export ITER=$(($ITER+1)); do :;
> done
>
> Usually 100-200 iterations will be enough.
> To catch the error more faster one can add wal_records column to SELECT
> in line 26 of contrib/pg_stat_statements/sql/pg_stat_statements.sql as
> followes:
> SELECT query, calls, rows, wal_records,
> and replace the contrib/pg_stat_statements/expected/pg_stat_statements.out
> with attached pg_stat_statements-fast.out
Can the test failures be encountered without such an elaborate setup? If not,
then I don't really see why we need to do anything here?
Greetings,
Andres Freund