Я понимаю, что я опоздал на дискуссию про pg_dump, но

я всё же закину вопрос.

В процессе вашей дискуссии возникло ощущение, что pg_dump/pg_restore может не восстановить состояние БД.
Есть такой пример? (видел про не консистентное восстановление из-за не ACID DDL, но вопрос в том, может ли не восстановиться в принципе dump)

А ещё не напомните, какие объекты не восстанавливет pg_dump/pg_restore? Вроде бы пользователей, права доступа. Может быть что-то ещё?

Ну так именно этот дамп и не восстанавливается (возникает ошибка и теряются данные). Или определите, что такое "не восстановиться в принципе"? А то так можно считать, что если хотя бы одна команда из дампа выполнилась, то он "в принципе восстановился". ;)

> Или определите, что такое "не восстановиться в принципе"? К примеру, в процессе восстановления возникает ошибка, т.е. восстановление прерывается.

Ээээ... по умолчанию psql / pg_restore игнорируют почти любые ошибки и продолжают до конца дампа, Вы не забыли?

Мб, не знал.

Тем не менее, это так. Поэтому, как мне кажется, невосстанавливаемый дамп — это когда случаются такие ошибки, и хотя бы часть данных не загружается.

Щас поясню. Всё там работает. Речь идёт про то, что не надо делать дамп в момент перезаписи таблицы. Точнее, наоборот: если вы используете уровни изоляции repeatable read и выше и при этом увлекаетесь ALTER TABLE, есть шанс нарваться на неприятности. Например, «видеть» пустую таблицу там, где она полная. pg_dump работает именно на уровне repeatable read. А юзеров дампит pg_dumpall. Пользуйтесь любыми постгресовыми инструментами на здоровье, но аккуратно! «Некоторые команды DDL, в настоящее время это TRUNCATE и формы ALTER TABLE, перезаписывающие таблицу, не являются безопасными с точки зрения MVCC. Это значит, что после фиксации усечения или перезаписи таблица окажется пустой для всех параллельных транзакций, если они работают со снимком, полученным перед фиксацией такой команды DDL.» https://postgrespro.ru/docs/postgresql/15/mvcc-caveats

Для тех кому интересно: Чуть более короткое воспроизведение: drop table if exists t; create table t (a int); insert into t values (1),(2),(3); begin; lock table t; =============== s2 begin isolation level repeatable read; select * from t; ================ s1 alter table t alter column a type bigint; commit; ================ s2 Не коммитим и пырим в «пустую» таблицу.

Про не транзакционность DDL я поянл. Думал есть пример, когда дамп может совсем не восстановиться. Ребята говорят, что ошибка проглатываются (а это значит, что не под транзакцией восстановление идёт, видимо).

Оно транзакционное. Но вот с этим ограничением.

Там, в примере, данные из таблицы вообще не сдампились.

Ага, но вот как раз пример показывает, что не транзакционное DDL.

> Всё там работает. Ага, аж шум стоит. Про все остальные продемонстрированные случаи Вы уже забыли, я так понимаю? ;) > Речь идёт про то, что не надо делать дамп в момент перезаписи таблицы. И если у Вас есть большие bytea, или "кривые" CHECK constraints, или криво написанные функции в них, или индексы на основании таких функций, или пользователь подложил Вам "удачный" mat.view (это вряд ли можно сделать не злонамеренно, правда), и т.д. и т.п. > Пользуйтесь любыми постгресовыми инструментами на здоровье, но аккуратно! Да-да, когда дампишь — главное не дышать. ;) Ладно, в любом случае, его непригодность в качестве средства для DR определяется не этим...

По умолчанию — без каких-либо транзакций, ошибки игнорируются (см. документацию). > Думал есть пример, когда дамп может совсем не восстановиться. Так что да, чтобы "совсем", нужно, чтобы проблема была в самом первом объекте, разве что — иначе какие-то "осколки" он в базу загрузит.

Вы можете дышать во время pg_dump. Можете не дышать. Можете не дышать и не дампить. Можете дышать и не дампить. Я ничего не имею против!

Не показывает. Не путайте ACID и транзакционность.

ACID - это свойства транзакции, не?

Ага. Но транзакции на уровне RC или RU — всё равно транзакции.