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

On 2026-Sep-25, Manu wrote:

> Hi,
>
> shihao zhong <zhong950419(at)gmail(dot)com> wrote:
> > Done in v5. 0001 is Álvaro's version as one commit, with that comment
> > added and a shorter commit message. 0002 fixes the decoding_ctx comment
> > in copy_table_data().
>
> I ran v5 through the same checks as v3, on master and on
> REL_19_STABLE, where it applies cleanly.

Thanks! I have pushed this. I apologize for forgetting to list
reviewers in the commit message :-( But I also failed to remember in
time that doing CheckRelationOidLockedByMe() doesn't actually check
anything, and that it needs to be used in conjunction with Assert(). I
have pushed a fix for that and wrote the "Reviewed-by" trailers there.

Anyway, regarding the patch, I changed some comments a little bit more.
The only change of actual significance is that I revisited my earlier
idea of not touching copy_table_data: I did change the lock acquisition
into an assert, when in concurrent mode. This is what Antonin had
suggested back in [1], and I thought would be "not very nice", but I
think I was mistaken.

[1] https://postgr.es/m/4324.1790317455@localhost

Regarding the deadlock when a conflicting lock on the toast table is
acquired during the initial steps, I'm not too worried about it; I think
it's on the spirit of "play stupid games, win you-know-what-kind-of-
prizes", and it hopefully won't be too bad in practice.

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"No necesitamos banderas
No reconocemos fronteras" (Jorge González)