| From: | PetSerAl <petseral(at)gmail(dot)com> |
|---|---|
| To: | Guillaume Lelarge <guillaume(at)lelarge(dot)info> |
| Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
| Subject: | Re: pg_dump and not MVCC-safe commands |
| Date: | 2024-05-20 10:36:08 |
| Message-ID: | CAKygsHRBRUhjGAQtqnbYPaXxJPvN2J49yS4ceee62iVG_jcuQQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
My question:
What happens if not MVCC-safe command committed after snapshot but before lock?
On Mon, May 20, 2024 at 12:33 PM Guillaume Lelarge
<guillaume(at)lelarge(dot)info> wrote:
>
> 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 | Kashif Zeeshan | 2024-05-20 10:48:53 | Re: How to update upper-bound of tstzrange ? |
| Previous Message | milist ujang | 2024-05-20 10:31:45 | signal 11: Segmentation fault ; query constraint list; pg16.3 |