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

From Antonin Houska
Subject Re: REPACK (CONCURRENTLY) can silently lose updates when the toast table is rewritten
Date
Msg-id 4324.1790317455@localhost
Whole thread
In response to Re: REPACK (CONCURRENTLY) can silently lose updates when the toast table is rewritten  (shihao zhong <zhong950419@gmail.com>)
Responses Re: REPACK (CONCURRENTLY) can silently lose updates when the toast table is rewritten
List pgsql-hackers
shihao zhong <zhong950419@gmail.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



pgsql-hackers by date:

Previous
From: solai v
Date:
Subject: Re: Add a permission check to pg_stat_get_backend_subxact()
Next
From: Peter Eisentraut
Date:
Subject: Re: Declare variable-length catalog columns as [] rather than [1]