ровно неделю назад. У меня еще archive_command была пустая, поэтому постгрес держал валы аж с нового года. Я ее поставил на true позавчера когда заметил что место на диске съедается.
>Да что он вообще может знать о процессах postgres?! 😉
>И я серьёзно, между прочим — запись в WAL такой процесс будет стараться откладывать — "за него" её почти наверняка будет выполнять что-то другое (тот backend, который делает свой commit); а запись в базу — checkpointer (на который Вы и видите жалобы в логах).
Да уж, я слышал что iotop нельзя использовать для мониторинга постгреса, ну вот что было)
pg_waldump показывает сплошь записи rmgr: Btree, это обновления индекса? Что-то в доках нет описания этих колонок которые эта утилита пишет...
Еще флаг --follow не дает никакого эффекта 🙁
> 12.5, апгрейднулся вот ровно неделю назад. Т.е. неизвестные bugs в логической репликации ни при чём, хотя бы. ;) > У меня еще archive_command была пустая, поэтому постгрес держал валы аж с нового года. И на источнике, и на приёмнике? > Я ее поставил на true позавчера И с тех пор всё нормализовалось? Кстати, почему бы не отключить архивирование, если оно не нужно (или уж, наоборот, настроить — что это Вы без архива живёте? ;) ). > записи rmgr: Btree, это обновления индекса? Да. И там вроде должны быть OID-ы, по которым можно найти, что это за индекс. И да, описания нет — исходники придётся смотреть, если интересует подробно... но и это и не нужно, обычно.
Не в тот WAL попали, например (в тот, что уже был ротирован). С высокой скоростью записи, даже если предварительно смотреть в postgres (pg_current_wal_lsn() и т.п.) и то можно промахнуться. ;)
Ааа, понятно! Этих 16-мб валов там по 20шт в минуту
Обсуждают сегодня