| From: | Antonin Houska <ah(at)cybertec(dot)at> |
|---|---|
| To: | shihao zhong <zhong950419(at)gmail(dot)com> |
| Cc: | Robert Treat <rob(at)xzilla(dot)net>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Manu <manuelreyesbravo(at)gmail(dot)com>, Thom Brown <thom(at)linux(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 06:24:15 |
| Message-ID: | 4324.1790317455@localhost |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
shihao zhong <zhong950419(at)gmail(dot)com> wrote:
> > (What I said does not mean that I'm in favor of restarting the decoding worker
> > either. I still prefer locking the TOAST relation early, as I noted elsewhere
> > in the thread.)
>
> OK. v3 locks the TOAST relation before the worker starts, as Sawada-san
> first suggested. A rewrite of the TOAST relation now waits for REPACK,
> which I think is also what Robert asked for.
Thanks for the patch. I'm just not sure this is the best place to lock the
TOAST table: note that copy_table_data() locks it again.
I'd prefer locking it close to the place we lock the main table (perhaps in
cluster_rel(), after all the checks have been done?) and replace the locking
statements (both in the copy_table_data() and in your patch) with
Assert(CheckRelationLockedByMe(...)).
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2026-09-25 06:36:02 | Re: Declare variable-length catalog columns as [] rather than [1] |
| Previous Message | solai v | 2026-09-25 06:23:22 | Re: Add a permission check to pg_stat_get_backend_subxact() |