| From: | Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
| Cc: | Antonin Houska <ah(at)cybertec(dot)at>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Robert Treat <rob(at)xzilla(dot)net> |
| Subject: | Re: Adding REPACK [concurrently] |
| Date: | 2026-02-01 22:37:37 |
| Message-ID: | CADzfLwVy+6Kgj2P5s9=KeG0HJxPte=FBSengUQ4MFFtSgubj8A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hello!
> I'm not sure it's acceptable to cause other sessions to raise errors if
> they query the table being repacked (or a table repacked recently).
> That sounds extremely unpleasant. Imagine a long-running transactions
> that runs enormous queries for many hours or even days, being killed
> near the end because some DBA decided to run REPACK on a table.
It will not. It raises an error only for the case table will be "empty"
because REPACK switched to new with all tuples with REPACK xid and our
transaction treats that xid as running.
So, there is no regression here, it just changes from "see an empty table
because of MVCC violation" to "get error" in the exact situation.
I prefer the second.
Mikhail.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chao Li | 2026-02-01 22:44:29 | Re: Wake up backends immediately when sync standbys decrease |
| Previous Message | Alvaro Herrera | 2026-02-01 22:31:48 | Re: Adding REPACK [concurrently] |