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

On Wed, 23 Sept 2026 at 06:10, shihao zhong <zhong950419(at)gmail(dot)com> wrote:
>
> > or whether the relfilenode should be re-checked after the snapshot is built
>
> Holding the toast lock from the start deadlocks. A session that asks for
> AccessExclusiveLock gets an XID before it waits, and the decoding worker
> waits for all XIDs while it sets up.
>
> So the attached patch re-checks instead. Once the worker is set up it no
> longer waits for anyone, so the backend locks the toast table there and
> compares its relfilenode with the one the worker uses. If they differ, it
> starts a new worker. Nothing has been copied yet, so REPACK just carries on.
>
> 0002 adds a test to repack_toast.spec that fails without 0001.

Thanks guys.

I've tested your patches, and I can't reproduce the issue with them
applied. The test on its own fails successfully.

I do have a question relating to this:

+ UnlockRelationOid(toastrelid, ShareUpdateExclusiveLock);
+ stop_repack_decoding_worker();

Is there any opportunity for another rewrite to sneak in between these two?

Thom