| From: | shihao zhong <zhong950419(at)gmail(dot)com> |
|---|---|
| To: | Manu <manuelreyesbravo(at)gmail(dot)com> |
| Cc: | 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-23 05:09:48 |
| Message-ID: | CAGRkXqRYLtBRaMzdH+e7PMO-BRaWPPo37gvOx3C=jQ1uP4Cx7w@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> or whether the relfilenode should be re-checked after the snapshot is
built
Holding the toast lock from the start deadlocks. A session that asks for
AccessExclusiveLock gets an XID before it waits, and the decoding worker
waits for all XIDs while it sets up.
So the attached patch re-checks instead. Once the worker is set up it no
longer waits for anyone, so the backend locks the toast table there and
compares its relfilenode with the one the worker uses. If they differ, it
starts a new worker. Nothing has been copied yet, so REPACK just carries on.
0002 adds a test to repack_toast.spec that fails without 0001.
optional.
Thanks,
Shihao
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0001-Fix-REPACK-CONCURRENTLY-losing-updates-after-a-TO.patch | application/octet-stream | 6.5 KB |
| v1-0002-Test-TOAST-rewrite-during-REPACK-CONCURRENTLY-sta.patch | application/octet-stream | 6.6 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chao Li | 2026-09-23 05:09:58 | Re: Adding a range check on the sequence index from the publisher. |
| Previous Message | shveta malik | 2026-09-23 04:42:44 | Re: Distinguish publication exclusions in object addresses |