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 179031682043.622163.16451343164955142463@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,

shihao zhong <zhong950419@gmail.com> wrote:
> The rewrite gets the error if those finish within deadlock_timeout,
> otherwise REPACK does.

That matches what I see with v3 on master (e27f3b2cad7), using the
same checks as for v2.  With Thom's sequence (a transaction open for
3 s, VACUUM FULL of the TOAST relation meanwhile) and the default
deadlock_timeout of 1 s, REPACK got "deadlock detected" in all 6 runs.
With deadlock_timeout = 5s, REPACK finished and the VACUUM FULL got
the error in all 3.  No update was lost in any run; master loses it
every time.

One case differs from v2: a transaction that already has an XID runs
REINDEX on the TOAST relation, with no rewrite, during the startup.
On master and with v2, REPACK completes; with v3 it gets "deadlock
detected", at both timeouts.  ALTER TABLE on the table itself
deadlocks the same way on master, as you said.

repack_toast fails without 0001 and passed 20 of 20 runs with it;
check and the isolation suite pass.  The script and output are
attached.

Regards,
Manu

Attachment

pgsql-hackers by date:

Previous
From: Bertrand Drouvot
Date:
Subject: Re: Persist slot invalidations before publishing them
Next
From: vignesh C
Date:
Subject: Re: Up to 50x degradation in dblink performance when receiving notice traffic 19 vs 18