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

From: shihao zhong <zhong950419(at)gmail(dot)com>
To: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
Cc: Thom Brown <thom(at)linux(dot)com>, Antonin Houska <ah(at)cybertec(dot)at>, Robert Treat <rob(at)xzilla(dot)net>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Manu <manuelreyesbravo(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: REPACK (CONCURRENTLY) can silently lose updates when the toast table is rewritten
Date: 2026-09-25 15:29:50
Message-ID: CAGRkXqTQjpXjDRF_c6kz6E7XpruvbZfOHzpLwj6a5arjg97CSQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Sami Imseih 2026-09-25 15:41:30 parallel autovacuum: Propagate track_cost_delay_timing to parallel workers
Previous Message Ayush Tiwari 2026-09-25 15:24:58 Re: Add a pg_wal_preallocate() SQL function to eagerly create future WAL segments