From: | Guillaume Lelarge <guillaume(at)lelarge(dot)info> |
---|---|
To: | PetSerAl <petseral(at)gmail(dot)com> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: pg_dump and not MVCC-safe commands |
Date: | 2024-05-20 09:33:45 |
Message-ID: | CAECtzeUQ3hJYPM6k6_XqZLq=DygHbQ3+5YQLrv-ngcht2rQjQg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi,
Le lun. 20 mai 2024 à 11:27, PetSerAl <petseral(at)gmail(dot)com> a écrit :
> How pg_dump interact with not MVCC-safe commands?
>
> As I understand, pg_dump first take snapshot and then lock all tables
> it intended to dump. What happens if not MVCC-safe command committed
> after snapshot but before lock? From comment to pg_dump.c I understand
> that it may fail with 'cache lookup failed' error. But, can it happen,
> that pg_dump not fail, but instead capture inconsistent dump? For
> example TRUNCATE committed after snapshot and pg_dump will see result
> of TRUNCATE but not result of other commands in TRUNCATE transaction?
>
>
>
You can't truncate an already existing table while pg_dump is running.
TRUNCATE needs an exclusive lock, and pg_dump already has a lock on all
tables of the database it's dumping. So TRUNCATE will be blocked until
pg_dump finishes all its work.
(The same will happen for VACUUM FULL, CLUSTER and some (all?) ALTER TABLE
commands.)
--
Guillaume.
From | Date | Subject | |
---|---|---|---|
Next Message | Laura Smith | 2024-05-20 10:30:35 | How to update upper-bound of tstzrange ? |
Previous Message | Alban Hertroys | 2024-05-20 09:30:29 | Re: Updating 457 rows in a table |