From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | PetSerAl <petseral(at)gmail(dot)com> |
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 14:24:02 |
Message-ID: | 3508051.1716215042@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
PetSerAl <petseral(at)gmail(dot)com> writes:
> My question:
> What happens if not MVCC-safe command committed after snapshot but before lock?
Then you'd get a dump that's not exactly consistent with the state
at the time of the snapshot. However, it would be the very same
database state that any other query would see at that time. So
if it's functionally inconsistent for your purposes, then you brought
that on your own head by using TRUNCATE concurrently with other
operations.
The other thing I can think of that's a hazard in this area is
that pg_dump will record current values of sequence objects that
may be advanced beyond where the sequence was at the instant of
the snapshot, since nextval() isn't MVCC-safe. There are a lot
of other ways (rollbacks and crashes) in which a sequence can get
advanced beyond the last derived value you can find in the database,
so an application that finds this to be unacceptable should probably
not be using sequences.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | PetSerAl | 2024-05-20 15:49:46 | Re: pg_dump and not MVCC-safe commands |
Previous Message | Rich Shepard | 2024-05-20 12:33:37 | Re: Updating 457 rows in a table |