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 CAGRkXqTQjpXjDRF_c6kz6E7XpruvbZfOHzpLwj6a5arjg97CSQ@mail.gmail.com
Whole thread
In response to Re: REPACK (CONCURRENTLY) can silently lose updates when the toast table is rewritten  (Álvaro Herrera <alvherre@kurilemu.de>)
List pgsql-hackers
> (Also, I would push both things as a single commit.)

Fine with me. I kept the test separate only because committers sometimes
push the fix without the test.

Taking the full lock upfront brings back the deadlock Manu found, where
a transaction the worker waits for runs REINDEX on the TOAST relation.

That is the same kind of case as DDL on the table itself, so I'm fine
with it.

Thanks,
Shihao

pgsql-hackers by date:

Previous
From: Ayush Tiwari
Date:
Subject: Re: Add a pg_wal_preallocate() SQL function to eagerly create future WAL segments
Next
From: Sami Imseih
Date:
Subject: parallel autovacuum: Propagate track_cost_delay_timing to parallel workers