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

From Manu
Subject Re: REPACK (CONCURRENTLY) can silently lose updates when the toast table is rewritten
Date
Msg-id 179036565943.2118102.16573869613641283994@gmail.com
Whole thread
In response to Re: REPACK (CONCURRENTLY) can silently lose updates when the toast table is rewritten  (shihao zhong <zhong950419@gmail.com>)
List pgsql-hackers
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.

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

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Cleaning up pgcrypto/crypt-des.c to avoid compiler warnings
Next
From: Sami Imseih
Date:
Subject: Re: REPACK (CONCURRENTLY) can lose data in pg_dump output