| From: | Thom Brown <thom(at)linux(dot)com> |
|---|---|
| To: | Sami Imseih <samimseih(dot)pg(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: REPACK (CONCURRENTLY) can lose data in pg_dump output |
| Date: | 2026-09-27 08:03:15 |
| Message-ID: | CAA-aLv6dq1FiC3TOtP6V+sLCnUiRzpcOKi-WApnbXkR2JTgsZA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 25 Sept 2026 at 20:50, Sami Imseih <samimseih(dot)pg(at)gmail(dot)com> wrote:
>
> Hi,
>
> > I realise REPACK (CONCURRENTLY) is documented as not being MVCC-safe,
> > Should this at least be documented on the pg_dump page, or could [...]
>
> Yeah, this is expected and not specifically introduced by REPACK. Any
> command that rewrites the table will also store the rows with a new
> xmin, so these rows are now not visible to a transaction that has a
> snapshot that pre-dates the rewrite. pg_dump runs in REPEATABLE READ
> isolation level and has a transaction snapshot, so it will not see the
> rewritten rows. A query inside a STABLE/IMMUTABLE function even when run
> through a READ COMMITTED transaction will also have the same behavior.
>
> You can repro the same behavior with an ALTER TABLE...ALTER COLUMN:
Ah, of course, I guess I was so focused on finding data loss that I
neglected to consider the pre-existing gaps.
Thanks for pointing that out.
Thom
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ayush Tiwari | 2026-09-27 08:41:53 | Re: FIX: BUG #19687: ALTER SEQUENCE missing lock |
| Previous Message | Alexandre Felipe | 2026-09-27 06:36:04 | Re: FIX: BUG #19687: ALTER SEQUENCE missing lock |