Re: REPACK (CONCURRENTLY) can silently lose updates when the toast table is rewritten

On 2026-Sep-25, Thom Brown wrote:

> Moving it into cluster_rel() makes sense, but does it need to be the
> full ShareUpdateExclusiveLock there?

Yeah, it's better to acquire the lock you want upfront, because
otherwise you introduce more risk of deadlock caused by lock upgrades
(admittedly the user would have to be doing something really stupid in
order for this to be a real problem, but still.) It's only AEL that we
don't want to hold for long.

Maybe the patch could be somewhat like this, then? I didn't review the
test carefully other than running without the code fix to verify that it
fails, and then passes with the fix; and I didn't read the commit
messages either, which I think are LLM-written and not really correct.
(Also, I would push both things as a single commit.)

I think changing the lock as obtained by copy_table_data is not very
nice, because that one is unconditional, and here we only want it in
concurrent mode. BTW I noticed that the comment for copy_table_data
mentions decoding_ctx as an argument, which doesn't exist.

--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"Nunca se desea ardientemente lo que solo se desea por razón" (F. Alexandre)