Что значит “рабочие селекты” и что значит “падают”?

количество полученных, обновлённых записей

А почему Вы думаете, что это связано именно с locking (как Вы это выяснили)?

видна корреляция так как обычная нагрузка очень ровная, а тут сразу растут локи, падает чтение/изменение

кол-во локов не важно, важно кол-во блокировок же!

да, ни конфликтов, ни дедлоков нет, но я ожидал, что вообще не будет так сильно аффектить чтение, ладно access локи растут, но на селекты почему так сильно влияет, вот что удивило

Ну так дамп это всё равно какая-то нагрузка, может быть дело только в этом? Т.е. как/насколько падает и т.п. (так как locking в pg_dump не отключишь, тут можно либо косвенно это проверять... либо снять "трассу" (логи) того, что делает pg_dump (на тестовой базе с идентичной схемой), "порезать" её так, чтобы можно было выполнить в psql (и убрать оттуда LOCK, конечно), и запустить на рабочей ;) )?

собственно для экспериментов я и хочу схему локально развернуть) и вот эксперимент с первой попавшейся тулзой вот такой результат дал, вот и спрашиваю, может есть и другие способы, а с pg_dump - это неэффективно и все давно юзают другое решение

> собственно для экспериментов я и хочу схему локально развернуть) Ну так потерпите один раз (если не хотите выяснять, в чём дело), подумаешь. ;) > а с pg_dump - это неэффективно и все давно юзают другое решение pg_dump же это делает не просто так, а чтобы [с большой вероятностью] снять схему консистентно. Если какое-то другое решение не будет накладывать этих locks, то и надёжность в этом отношении будет ниже.

ну, схема всё-таки не так часто меняется и я бы вполне согласился поставить флажок "облегчённого дампа с меньшей вероятностью")

А для чего вам нужно часто дамп схемы снимать?

1. Вы же пока только предполагаете, что дело в этом. ;) 2. А так — patches welcome, как говорится (но в связи с (1), когда Вы напишете patch, при его тестировании может оказаться, что дело-то не в locks...).

про частоту никто не говорил

Тогда можно просто снимать дамп тогда, когда у вас минимальная нагрузка. Это не решает проблему?

реплики нет, про снятие в самое минимальное по нагрузке время тоже думал, но вопрос опять же про историю "спрошу у опытных ребят, подскажут оптимальное решение вместо перебора всех вариантов")

А для чего вам вообще снятие дампа на регулярной основе? Возможно, если в вашем приложении есть миграции, то удобней просто их запускать и всё?

тоже в курсе миграций, только если их нет, немного сложнее становится)

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

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

Тогда ваш вопрос теряет актуальность, ведь вам тогда нужно всего один раз снять структурный дамп.

вопрос не теряет актуальность, если его рассматривать с академической точки зрения, собственно, я с этой точки его и рассматриваю тут больше не про поиск любого рабочего решения, а про поиск лучшего решения

Тут вряд ли подскажу, но за свой опыт работы не сталкивался ни разу с необходимостью периодически снимать структурный дамп базы, хотя каких костылей только не видел. Хотя так можно отслеживать для чего-нибудь, когда сменится структура базы, сравнивая два дампа с помощью diff