А почему запрос который я привёл и его вывод не подходит?

relation            | blocked_pid |                                                          blocked_query                                                          | blocked_mode | blocking_pid |                                                 blocking_query                                                  |  blocking_mode
-------------------------------+-------------+---------------------------------------------------------------------------------------------------------------------------------+--------------+--------------+-----------------------------------------------------------------------------------------------------------------+------------------
delivery_order_metric_2021_03 |       10194 | insert into delivery_order_metric (creation_date, merchant_id, order_id, payload, pos_id, type) values ($1, $2, $3, $4, $5, $6) | ShareLock    |        31804 | SELECT commit_fk, property_name, property_value FROM jv_commit_property WHERE commit_fk in (37330559,37330558)  | RowExclusiveLock
delivery_order_metric_2021_03 |       10194 | insert into delivery_order_metric (creation_date, merchant_id, order_id, payload, pos_id, type) values ($1, $2, $3, $4, $5, $6) | ShareLock    |        31804 | SELECT commit_fk, property_name, property_value FROM jv_commit_property WHERE commit_fk in (37330559,37330558)  | ShareLock
(2 rows)

Потому что мне удобнее посмотреть в первоисточник а не в результат джоина. Если это сделать нельзя, потому что поезд уже ушёл - то так и скажите. ShareLock конфликтует с RowExclusiveLock, так что insert может его ждать.

тут было бы полезно видеть что blocking_pid делает (query, state)

А что даст эта информация?

Да я знаю что они конфликтуют, вопрос откуда он берётся, откуда берётся rowexclusivelock понятно, но почему инсерт пытается получить sharelock не понятно

А он не пытается. Вы бы показали то, что просят.

Результат запроса который вывод содержимое pg_lock которые удалось поймать во время теста, я привёл выше. Сейчас нужной нагрузки  нет, я правда не могу понять почему этот зарос хуже

потому что он показывает только то, что вы кого-то ждёте. чтобы ответить кого и почему — нужно больше информации

потому что он показывает только то, что вы кого-то ждёте. чтобы ответить кого и почему — нужно больше информации

Результат запроса который вывод содержимое pg_lock которые удалось поймать во время теста, я привёл выше. Сейчас нужной нагрузки  нет, я правда не могу понять почему этот зарос хуже

Потому что в pg_locks может быть и другая полезная информация.
Кроме того, он вводит в заблуждение (вот Вас, например, ввёл).  ;)
Блокировки удерживают не запросы, а транзакции. Поэтому "blocking_query" в запросе означает не то, что Вы думаете.

> В логах видно что инсерт ждёт sharelock, вопрос зачем

И в логах, и в этом запросе видно, что данный INSERT ждёт наложенный чем-то другим ShareLock, нет?

я ситуации с блокировками смотрю вот этим скриптом: https://github.com/dataegret/pg-utils/blob/master/sql/locktree.sql

То что в запросе блокирующий sql может быть не тот что на самом деле, я понимаю, но то что инсерт пытается получить sharelock на таблицу по-моему это следует из этого запроса и из логов, и мой вопрос именно в том почему insert пытается получить эту блокировку, когда по документации она ему не нужна

Спасибо!