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

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.

With the test but without the code change, repack_toast fails in
s1_check: 10 rows of s2's updates are missing, not just the lock
timeout line. With v5 it passed 30 of 30 runs, and 30 of 30 with the
run pinned to one CPU, since the new permutation depends on
lock_timeout and the (*) marker.

The core regression and isolation suites pass on both branches. In
the behaviour checks no update was lost. A rewrite or REINDEX of the
TOAST relation from a transaction the worker waits for now ends in a
deadlock error, as discussed: REPACK is the one cancelled at a 1s
deadlock_timeout, the other session at 5s.

The output and scripts are attached.

Regards,
Manu