q
ctrl + d

пришлось убить терминал) ни че не помогло хз че это было) больше не буду смотреть через терминал) пгадмин настало твое время!

Выглядит так, будто какой-то редактор запущен. Из которого, скорее-всего, можно было выйти как :q (или просто q)

это не редактор, а pager less. перед запуском терминала сделайте export LESS=-eXF
в ситуациях как на картинке выше помогает клавиша q

Да, может быть такое

Я всегда думал что это vim)

почитайте про psql и опцию PAGER

Как по практике, так же было дело, сразу не заметил что раскладка не латиница, и просто не воспринимал нажатия))

подскажите как ловить исключения из dblink

(наверно очень тупой вопрос). Как я могу как клиент базы понять лимит данных на вставку, что бы не складывать базу? Иногда я кладу слишком много, получаю либо убиение процесса по лимиту  памяти, либо просто получаю EOF и в логе что я превысил буфер.

Добрый вечер. Перевел бизнес логику в хранимые процедуры и стал отлавливать такое

ERROR:  deadlock detected
DETAIL:  Process 16867 waits for ShareLock on transaction 20266082; blocked by process 17093.
Process 17093 waits for ShareLock on transaction 20266035; blocked by process 16867.
HINT:  See server log for query details.
CONTEXT:  while updating tuple (935,46) in relation "storehouse_remain"
SQL statement "UPDATE storehouse_remain r SET outgo = COALESCE(
        (SELECT SUM(iu.weight) FROM storehouse_itemusage iu
        WHERE iu.item_id = rec.item_id AND iu.storehouse_id = rec.storehouse_id AND iu.type = 'u'
          AND iu.created_at >= r.created_at), 0)
    WHERE r.id = remain_id"
PL/pgSQL function update_remain_outgo() line 12 at SQL statement
SQL statement "DELETE FROM storehouse_itemusage WHERE referrer_id = referrerid"

Я так понимаю, что перед тем, как делать SELECT SUM(iu.weight) FROM storehouse_itemusage iu
       WHERE iu.item_id = rec.item_id AND iu.storehouse_id = rec.storehouse_id AND iu.type = 'u'
         AND iu.created_at >= r.created_at

нужно эти записи залочить

Может проблема в архитектуре и нужна очередь. Слишком много это в одном запросе?

Как обычно, по идее... а в чём проблема?

это в одном insert. но как бы я хотел бы перед стартом, порсить базу о конфигурации, и примерно для себя приложении выстроить лимиты. но пока плохо понимаю как

Если обычно это так EXCEPTION
       WHEN OTHERS THEN то не отлавливаються

Нужно разобраться, что конкретно и почему происходит (потому что подобного встроенного "лимита" просто нет).

ERROR:  deadlock detected
DETAIL:  Process 16867 waits for ShareLock on transaction 20266082; blocked by process 17093.
Process 17093 waits for ShareLock on transaction 20266035; blocked by process 16867.
HINT:  See server log for query details.
CONTEXT:  while updating tuple (935,46) in relation "storehouse_remain"
SQL statement "UPDATE storehouse_remain r SET outgo = COALESCE(
        (SELECT SUM(iu.weight) FROM storehouse_itemusage iu
        WHERE iu.item_id = rec.item_id AND iu.storehouse_id = rec.storehouse_id AND iu.type = 'u'
          AND iu.created_at >= r.created_at), 0)
    WHERE r.id = remain_id"
PL/pgSQL function update_remain_outgo() line 12 at SQL statement
SQL statement "DELETE FROM storehouse_itemusage WHERE referrer_id = referrerid"

Нужно обрабатывать deadlocks, как положено (повторять транзакции). Если на производительность это существенно не влияет, то на этом и всё.

Я их повторяю, это да. Я читал, что в PG 11 вроде появились процедуры и функции и разница там как раз в уровне изоляции данных. И показалось, что может я использую процедуры, а нужно функции.

Хмм... а какое там исключение бросается? Насколько сложно сделать repro?

жесткий был такой -

server process (PID 464) was terminated by signal 9: Killed
Failed process was running: INSERT INTO assignment AS "t" (...
terminating any other active server processes

потом я подкорретировал настроки базы под размер cpu и ram сервера.

ситуация улучшилась, но все равно
DE

TAIL:  Cannot enlarge string buffer containing 0 bytes by 1165680927 more bytes.

и постоянно перенастраивать код под ресурсы базы - не комильфо. думал как то (хотя бы примерно) оценить тяжесть вставки. и перед вставкой его почикать на куски подходящие.