Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements
Дата
Msg-id 1555691.1648945802@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements  (Greg Stark <stark@mit.edu>)
Список pgsql-hackers
Greg Stark <stark@mit.edu> writes:
> The tests for this seem to need adjustments.
> [12:41:09.403] test pg_stat_statements ... FAILED 180 ms

> diff -U3 /tmp/cirrus-ci-build/contrib/pg_stat_statements/expected/pg_stat_statements.out
> /tmp/cirrus-ci-build/contrib/pg_stat_statements/results/pg_stat_statements.out
> --- /tmp/cirrus-ci-build/contrib/pg_stat_statements/expected/pg_stat_statements.out
> 2022-04-02 12:37:42.201823383 +0000
> +++ /tmp/cirrus-ci-build/contrib/pg_stat_statements/results/pg_stat_statements.out
> 2022-04-02 12:41:09.219563204 +0000
> @@ -1174,8 +1174,8 @@
>  ORDER BY query;
>             query           | reset_ts_match
>  ---------------------------+----------------
> - SELECT $1,$2 AS "STMTTS2" | f
>   SELECT $1 AS "STMTTS1"    | t
> + SELECT $1,$2 AS "STMTTS2" | f
>  (2 rows)

>  -- check that minmax reset does not set stats_reset

> Hm. Is this a collation problem?

Yeah, looks like it.  ORDER BY query COLLATE "C" might work better.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.
Следующее
От: Noah Misch
Дата:
Сообщение: Re: Skipping logical replication transactions on subscriber side