On 1/29/26 9:58 AM, PetSerAl wrote:
On Thu, Jan 28, 2026 at 8:32 PM Guillaume Lelarge
<[email protected]> wrote:
Doesn't matter at all. You'll get a consistent backup.
But be aware of not MVCC-safe commands like TRUNCATE.
If transaction with such command intersect with beginning of backup,
then it may be not consistent.
It will see effects of TRUNCATE, but will not see effects of other
commands in such transaction.
From here:
https://www.postgresql.org/docs/current/mvcc-caveats.html
"Some DDL commands, currently only TRUNCATE and the table-rewriting
forms of ALTER TABLE, are not MVCC-safe. This means that after the
truncation or rewrite commits, the table will appear empty to concurrent
transactions, if they are using a snapshot taken before the DDL command
committed. This will only be an issue for a transaction that did not
access the table in question before the DDL command started — any
transaction that has done so would hold at least an ACCESS SHARE table
lock, which would block the DDL command until that transaction completes."
And the more general case described here:
https://www.postgresql.org/message-id/[email protected]
"
> My questions are: can making DDL changes during a dump cause this
error? Are the queries used by pg_dump transactionally consistent, i.e.
do they run in a transaction and get a single view of the database
system catalogs? Other than finer coordination of jobs, how can this
situation be avoided?
...
The window for this sort of thing isn't very large, because the first
thing pg_dump does is acquire AccessShareLock on every table it intends
to dump, and past that point it won't be possible for anyone to modify
the table's DDL. But it can happen.
...
"
There is a small window for this happening in any case. Read the rest of
the case for suggestions to mitigate.
