On Wed, 23 Sept 2026 at 06:10, shihao zhong <[email protected]> wrote: > > > 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.
Thanks guys. I've tested your patches, and I can't reproduce the issue with them applied. The test on its own fails successfully. I do have a question relating to this: + UnlockRelationOid(toastrelid, ShareUpdateExclusiveLock); + stop_repack_decoding_worker(); Is there any opportunity for another rewrite to sneak in between these two? Thom
