MIME-Version: 1.0
References: <CAKygsHQHhd4rzYcNCd8OJMH46saT1E+9+5MT2CgOCGgf_yaQAw@mail.gmail.com>
 <CAECtzeUQ3hJYPM6k6_XqZLq=DygHbQ3+5YQLrv-ngcht2rQjQg@mail.gmail.com>
 <CAKygsHRBRUhjGAQtqnbYPaXxJPvN2J49yS4ceee62iVG_jcuQQ@mail.gmail.com> <3508051.1716215042@sss.pgh.pa.us>
In-Reply-To: <3508051.1716215042@sss.pgh.pa.us>
From: PetSerAl <petseral@gmail.com>
Date: Mon, 20 May 2024 18:49:46 +0300
Message-ID: <CAKygsHS2rKkzRFh-SygCjR-TGLhpbWxci4Ms5BxoJ9KJ5DXhxA@mail.gmail.com>
Subject: Re: pg_dump and not MVCC-safe commands
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Guillaume Lelarge <guillaume@lelarge.info>, pgsql-general@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://www.postgresql.org/message-id/CAKygsHS2rKkzRFh-SygCjR-TGLhpbWxci4Ms5BxoJ9KJ5DXhxA%40mail.gmail.com>
Precedence: bulk

> However, it would be the very same
> database state that any other query would see at that time.
Other queries can use different techniques to prevent this. For
example, lock tables before snapshot, as recommended in documentation.
I understand, that pg_dump can not use that, as it need snapshot to
enumerate tables to lock.

> then you brought
> that on your own head by using TRUNCATE concurrently with other
> operations.
People, who admins database servers, are not always the same people,
who write application/queries. That means, if you know nothing about
application, you can not guarantee, if live database backup would be
consistent. Basically, you need application cooperation to make
consistent live database backup.