дамп базы через сеть с архивированием

Почему это самый тяжелый случай и чем он принципиально отличается от «Простое»?

Потому что в «простом» случае произойдёт самый быстрый дамп и сервер будет залочен минимальное время.

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

Понятно, что если дамп длится считанные минуты, да ещё когда-нибудь ночью, разница будет невелика. А если там гигабайт? Десять гигабайт?

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

Это можно как нибудь проверить?

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

Это можно как нибудь проверить?

Пока идёт дамп большой таблицы попробуй туда что-то записать. А потом — ещё раз. Запросы должны встать в очередь. Я не в курсе тонкостей залочки в postrgre, но по логике должно быть так.

Ведь до выполнения xz pg_dump уже должен отработать

Нет. Пайп буферизируется, но он не примет все гигабайты. Так что pg_dump будет висеть почти до конца процесса упаковки, отдавая понемногу данные, которые будет также понемногу паковать xz и также понемногу передавая в сеть.

резонно

Просто я на этих граблях натанцевался много лет назад ещё в mysql. А сейчас они уже что-то типа FAQ'а по оптимизации. В результате пошёл сперва именно по простому пути (дамп и потом сжатие), а когда и оно не стало справляться (только дамп в файл длится минут 10—20), то перешёл на репликацию.

Правда, сейчас открыл для себя Percona XtraBackup, оно работает прямо с файлами базы данных и потому очень быстро, но там есть много своих капризов, которые пока не дают использовать на практике (например, штатно оно восстанавливает целиком всю БД, а мне часто надо вытаскивать отдельные таблицы).

Пока идёт дамп большой таблицы попробуй туда что-то записать. А потом — ещё раз. Запросы должны встать в очередь.

Нет, в postgres будет всё работать параллельно, и резервное копирование таблиц и их чтение/запись. Единственное что будет заблокировано, это alter table и т.п. копируемой таблицы.

Правда, сейчас открыл для себя Percona XtraBackup, оно работает прямо с файлами базы данных и потому очень быстро

У postgres один из штатных режимов резервного копирования такой есть, на уровне файлов с последующим их восстановлением по WAL при запуске копии.