> (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
v3-0002-Test-TOAST-rewrite-during-REPACK-CONCURRENTLY-sta.patch
Description: Binary data
v3-0001-Fix-REPACK-CONCURRENTLY-losing-updates-after-a-TO.patch
Description: Binary data
