идентификаторы лучше называть латиницей, и только в нижнем регистре с "_".

Я всё переименовал, но проблема осталась

очевидно используется разный пользователь

Господииии, я не в ту БД подключался...

🤷🏼‍♂️

Приветствую!

Добрый день, с новым годом.
Я делаю прометеус алерты для своего постгреса 9.6. Мониторю постгрес экспортером (докер образ`wrouesnel/postgres_exporter`).
Добавил алерт для долгоживущих транзакций, т.к. знаю что держать блокировки подолгу это плохо в постгресе:

pg_stat_activity_max_tx_duration{state="idle in transaction"} > 300 # Alert on transaction if it is idle more than 5 minutes

Тут случилась беда: прометеус начал спамить алертами по одной из баз. По его данным транзакции жили в простое по часу и более.
В связи с этим у меня возникло пара вопросов:
* есть ли какое-то обощённое время жизни транзакций которое считается "плохим"? Быть может мои транзакции с временем жизни по часу это нормальная ситуация? Быть может мне надо просто отрегулировать алерт для отдельно взятой базы?
* кто должен чинить простаивающие транзакции: программисты приложения или администратор постгреса?
* как чинить такие транзакции? как-то принудительно завершать или всё же ждать их завершения?

pg_stat_activity_max_tx_duration{state="idle in transaction"} > 300 # Alert on transaction if it is idle more than 5 minutes

В общем случае - долгие транзакции - это плохо. Час - точно причина сесть и разобраться. Разбираться надо совместно, админу промониторить какие конкретно запросы висят в транзакции и в каком именно статусе, программистам и ответственным за логику приложения обьяснить - нормально ли их появление и нормален ли тут час. Чинить транзакции в общем случае надо починкой запросов, которые их вызывают. Там может быть ожидание диска, результатов другой транзакции, внешнего ресурса и прочее-прочее. Рвать их - значит уничтожать результат их работы. А их явно не для того писали.

справедливости ради, есть подход, когда мы рвём всё, что дольше N минут и потом разбираемся почему та или иная транзакция затупила, иногда делая исключения для каких-то случаев.

это если команда заранее об этом договорилась, согласна и вообще есть консенсус по вопросам зон ответственности. Судя по формулировке вопроса - его даже близко нет

pg_stat_activity_max_tx_duration{state="idle in transaction"} > 300 # Alert on transaction if it is idle more than 5 minutes

> есть ли какое-то обощённое время жизни транзакций которое считается "плохим"?

Нет, но существенный простой — это не нормально, и почти наверняка говорит об ошибке работы с транзакциями в приложении-клиенте.

> Быть может мои транзакции с временем жизни по часу это нормальная ситуация?

Речь же не о времени жизни? Вот час простоя, например — это ненормально.

> Быть может мне надо просто отрегулировать алерт для отдельно взятой базы?

Почти наверняка нет.

> Кто должен чинить простаивающие транзакции: программисты приложения или администратор постгреса?

Программисты, конечно — это их ошибка, DBA тут ничего хорошего не сделает.

> как чинить такие транзакции?

Понятно, как — не забывать закрывать транзакции.

> как-то принудительно завершать или всё же ждать их завершения?

Вы про то, что может сделать DBA? Можно idle_in_transaction_session_timeout установить, например.

pg_stat_activity_max_tx_duration{state="idle in transaction"} > 300 # Alert on transaction if it is idle more than 5 minutes

> * есть ли какое-то обощённое время жизни транзакций которое считается "плохим"?
Есть «очень плохое»: когда 32-битный идентификатор транзакций перематывается взад и вся база встает.

вы про transaction id wrap around говорите?

А вообще кто-нибудь рассматривал вариант «алерты криво настроены»?

Транзакция на час — это либо хана производительности, либо какой-то разовый аналитический запрос (черт с ним), либо как раз криво настроенный мониторинг.

мне кажется, что в базе имеются транзакции сильно дольше заявленного лимита. если не было мониторинга и его внезапно включают то, как правило, много интересного вылазит

Не, ну есть еще вариант, что программисты научили программу делать BEGIN и уходить спать на два часа. Но это надо как-то специально стараться.
Но обычно транзакция на час — это что-то кривое и тяжелое, что, будучи запущенным пять раз подряд, убивает сервер.

Хелп! Застряла логическая репликация, WALы собираются!

Я создал новую публикацию на мастере с парой таблиц, потом закинул в публикацию десяток новых таблиц и сделал ALTER SUBSCRIPTION ... REFRESH PUBLICATION. Потом заметил что одна таблица лишняя (`account`), удалил ее из публикации и сделал рефреш. 10 часов спустя, в логах слейва вот это:

"logical replication target relation ""public.account"" does not exist"
"background worker ""logical replication worker"" (PID 11488) exited with exit code 1"
"logical replication apply worker for subscription "core0_denali"" has started"

Все таблицы уже сделали свою initial COPY, осталась только эта удаленная из публикации таблица которая не дает реплике прожевать WALa. Что можно сделать чтоб не начинать все сначала?

Еще вот такое иногда пишет между тех строк выше:

"could not start WAL streaming: ERROR:  replication slot ""core0_denali"" is active for PID 23511"

Ок, волы начали поедаться после того как я создал схему для этой таблицы на реплике. Только вот лог ругается на пяток мелких таблиц (размером несколько КБ каждая), что не может вставить из COPY потому что там уже есть эти pkeys. Может ли быть такое что моя комада REFRESH PUBLICATION запустила процедуру копии во второй раз, не записав что изначальная копия этих мелких таблиц уже производилась?