> (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
