| From: | PetSerAl <petseral(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Guillaume Lelarge <guillaume(at)lelarge(dot)info>, pgsql-general(at)lists(dot)postgresql(dot)org |
| Subject: | Re: pg_dump and not MVCC-safe commands |
| Date: | 2024-05-20 15:49:46 |
| Message-ID: | CAKygsHS2rKkzRFh-SygCjR-TGLhpbWxci4Ms5BxoJ9KJ5DXhxA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
> 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christophe Pettus | 2024-05-20 15:53:58 | Re: pg_dump and not MVCC-safe commands |
| Previous Message | Tom Lane | 2024-05-20 14:24:02 | Re: pg_dump and not MVCC-safe commands |