| From: | shihao zhong <zhong950419(at)gmail(dot)com> |
|---|---|
| To: | Antonin Houska <ah(at)cybertec(dot)at> |
| Cc: | Robert Treat <rob(at)xzilla(dot)net>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Manu <manuelreyesbravo(at)gmail(dot)com>, Thom Brown <thom(at)linux(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: REPACK (CONCURRENTLY) can silently lose updates when the toast table is rewritten |
| Date: | 2026-09-25 04:32:11 |
| Message-ID: | CAGRkXqR+jco=86v10goPL5jQbKJJcK_dwWB_4dFh4CEDnN7jpg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> (What I said does not mean that I'm in favor of restarting the decoding
worker
> either. I still prefer locking the TOAST relation early, as I noted
elsewhere
> in the thread.)
OK. v3 locks the TOAST relation before the worker starts, as Sawada-san
first suggested. A rewrite of the TOAST relation now waits for REPACK,
which I think is also what Robert asked for.
The deadlock I mentioned only happens if the rewrite starts while the
worker still waits for older transactions. The rewrite gets the error if
those finish within deadlock_timeout, otherwise REPACK does. Nothing is
lost either way. ALTER TABLE on the table itself hits the same deadlock
on master today.
0002 is the test. The rewrite there uses lock_timeout,
so the result does not depend on which side the deadlock detector picks.
Thanks,
Shihao
| Attachment | Content-Type | Size |
|---|---|---|
| v3-0002-Test-TOAST-rewrite-during-REPACK-CONCURRENTLY-sta.patch | application/octet-stream | 7.2 KB |
| v3-0001-Fix-REPACK-CONCURRENTLY-losing-updates-after-a-TO.patch | application/octet-stream | 3.5 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | vignesh C | 2026-09-25 04:38:54 | Re: Up to 50x degradation in dblink performance when receiving notice traffic 19 vs 18 |
| Previous Message | shihao zhong | 2026-09-25 04:22:09 | Re: Add a permission check to pg_stat_get_backend_subxact() |