Если нужна реплика, то логично и мониторить её статус и размер wal.
А собирать pg_probackup из исходников под арм не пробовали? Просто интересно (: Вроде бы он есть под арм для платных версий Postgres Pro, поэтому и для ванилы должен собираться
Ротация wal довольно легко настраивается. И, по-моему, по умолчанию ненужные wal автоматически удаляются. Ненужными они становятся после checkpoint и записи изменений на диск. Держать wal может слот репликации или параметр wal_keep_segments.
Либо у Вас checkpoint не выполнялся, что менее вероятно.
Хорошо, работает некорректно.
В целом там могут и другие проблемы быть, так как в расширении никаких изменений нет, а в СУБД есть.
Вы собирали расширение из https://github.com/postgrespro/pg_variables?
Там нет изменений 2 года, вполне логично, что не работает на PostgreSQL 18
Странно, логическая репликация не через WAL работает?
Может я не понял вопрос, но разве это не оно?
В postgres pro enterprise был свой встроенный пул до 16 версии https://postgrespro.ru/docs/enterprise/16/connection-pooler-configuration
Начиная с 17 версии вместо него https://postgrespro.ru/docs/enterprise/17/proxima
Из этого текста получается что pg_repack это и есть delete from. А это совсем не так.
И ещё не указаны ограничения pg_compacttable, он не работает с TPAST, а это может быть большей частью занятого места.
Вы придумали физическую репликацию?
Если нужна реплика, то логично и мониторить её статус и размер wal.
А собирать pg_probackup из исходников под арм не пробовали? Просто интересно (: Вроде бы он есть под арм для платных версий Postgres Pro, поэтому и для ванилы должен собираться
Ротация wal довольно легко настраивается. И, по-моему, по умолчанию ненужные wal автоматически удаляются. Ненужными они становятся после checkpoint и записи изменений на диск. Держать wal может слот репликации или параметр wal_keep_segments.
Либо у Вас checkpoint не выполнялся, что менее вероятно.