queryid - и дубль строки при вставке в pg_profile

[sgrinko]

Добрый день, Андрей!

У нас PG14 и последняя установленная версия pg_profile - VERSION "0.3.6" Неожиданно наткнулись на ситуацию, когда удалось получить дубликат записи при сборе статистики. Нам потребовалось включить параметр pg_stat_statements.track = top -> pg_stat_statements.track = all Для того, чтобы запросы, выполняемые внутри функций и процедур, были доступны в сборе статистики. И после некоторого интенсивного периода отладки (вызов одной и той же функции) при сборе очередного сэмпла мы получили вот такую ошибку:

00:10:49 db: postgres@profile_mon, pid:23551
=# SELECT profile.take_sample('sm-devpgsql-01.devel.ifx');
ERROR:  23505: duplicate key value violates unique constraint "pk_sample_statements_n"
DETAIL:  Key (server_id, sample_id, datid, userid, queryid)=(59, 1, 16384, 10, 12791009626215829) already exists.
CONTEXT:  SQL statement "INSERT INTO sample_statements(
          server_id,
          sample_id,
          userid,
          datid,
          toplevel,
          queryid,
          queryid_md5,
          plans,
          total_plan_time,
          min_plan_time,
          max_plan_time,
          mean_plan_time,
          stddev_plan_time,
          calls,
          total_exec_time,
          min_exec_time,
          max_exec_time,
          mean_exec_time,
          stddev_exec_time,
          rows,
          shared_blks_hit,
          shared_blks_read,
          shared_blks_dirtied,
          shared_blks_written,
          local_blks_hit,
          local_blks_read,
          local_blks_dirtied,
          local_blks_written,
          temp_blks_read,
          temp_blks_written,
          blk_read_time,
          blk_write_time,
          wal_records,
          wal_fpi,
          wal_bytes
        )
        VALUES (
            qres.sserver_id,
            qres.sample_id,
            qres.userid,
            qres.datid,
            qres.toplevel,
            qres.queryid,
            qres.queryid_md5,
            qres.plans,
            qres.total_plan_time,
            qres.min_plan_time,
            qres.max_plan_time,
            qres.mean_plan_time,
            qres.stddev_plan_time,
            qres.calls,
            qres.total_exec_time,
            qres.min_exec_time,
            qres.max_exec_time,
            qres.mean_exec_time,
            qres.stddev_exec_time,
            qres.rows,
            qres.shared_blks_hit,
            qres.shared_blks_read,
            qres.shared_blks_dirtied,
            qres.shared_blks_written,
            qres.local_blks_hit,
            qres.local_blks_read,
            qres.local_blks_dirtied,
            qres.local_blks_written,
            qres.temp_blks_read,
            qres.temp_blks_written,
            qres.blk_read_time,
            qres.blk_write_time,
            qres.wal_records,
            qres.wal_fpi,
            qres.wal_bytes
        )"
PL/pgSQL function collect_pg_stat_statements_stats(jsonb,integer,integer,integer) line 598 at SQL statement
SQL statement "SELECT collect_pg_stat_statements_stats(server_properties, sserver_id, s_id, topn)"
PL/pgSQL function take_sample(integer,boolean) line 646 at PERFORM
PL/pgSQL function take_sample(name,boolean) line 9 at RETURN
SCHEMA NAME:  profile
TABLE NAME:  sample_statements
CONSTRAINT NAME:  pk_sample_statements_n
LOCATION:  _bt_check_unique, nbtinsert.c:670
Time: 374.692 ms

Может быть можно что-то сделать, чтобы не падать? Режим pg_stat_statements.track = all нам нужен. Погрешность в виде сбора total нас устраивает.

[zubkov-andrei]

Добрый день, Сергей! Да, проблема известна как #38. Я над ней работаю, но решаю ее в рамках существенного изменения механизма сбора статистик выражений, как только добьюсь в этом деле стабильности, выпущу релиз.

[sgrinko]

Спасибо, ждём

[zubkov-andrei]

Поправлено в релизе 4.0

[sgrinko]

Спасибо большое, будем изучать новую версию!