Re: Possible fails in pg_stat_statements test

From: Andres Freund <andres(at)anarazel(dot)de>
To: "Anton A(dot) Melnikov" <aamelnikov(at)inbox(dot)ru>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Possible fails in pg_stat_statements test
Date: 2022-03-20 17:36:17
Message-ID: 20220320173617.uagjx65hfzpdpqmq@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2022-03-20 17:58:07 Re: a misbehavior of partition row movement (?)
Previous Message Anton A. Melnikov 2022-03-20 17:09:07 Re: Possible fails in pg_stat_statements test