Re: REPACK (CONCURRENTLY) can silently lose updates when the toast table is rewritten - Mailing list pgsql-hackers

From Álvaro Herrera
Subject Re: REPACK (CONCURRENTLY) can silently lose updates when the toast table is rewritten
Date
Msg-id arqEOe67h7Xeu4FB@alvherre.pgsql
Whole thread
In response to Re: REPACK (CONCURRENTLY) can silently lose updates when the toast table is rewritten  (Manu <manuelreyesbravo@gmail.com>)
List pgsql-hackers
On 2026-Sep-25, Manu wrote:

> Hi,
> 
> shihao zhong <zhong950419@gmail.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)



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [PATCH] Fix vacuum_delay_point happening inside lock
Next
From: Bertrand Drouvot
Date:
Subject: Re: Persist slot invalidations before publishing them