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

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

optional.
Thanks,
Shihao
Attachment

pgsql-hackers by date:

Previous
From: shveta malik
Date:
Subject: Re: Distinguish publication exclusions in object addresses
Next
From: Chao Li
Date:
Subject: Re: Adding a range check on the sequence index from the publisher.