Re: BUG #17268: Possible corruption in toast index after reindex index concurrently

On Mon, Nov 15, 2021 at 08:03:04PM +0900, Michael Paquier wrote:
> After more testing, I have been able to extract and write an isolation
> test that is able to reproduce the failure.  It relies on a trick as
> the toast relation names are not deterministic, and we cannot use
> REINDEX CONCURRENTLY in a function context.  So I have used an ALTER
> TABLE/INDEX RENAME with a DO block to change the toast relation
> names with allow_system_table_mods instead.  There is no need either
> for amcheck with this method.
> 
> 2) is enough to fix the problem, and I'd like to think that we had
> better stick with only this method for simplicity's sake.

I have been working on this one again for the last couple of days, and
I would still go with the simple solution, releasing the row-level
toast locks only at the end of the transaction when saving and
deleting a toast value.  While testing, I have noticed that the
deletion part is also important, as a REINDEX CONCURRENTLY run in
parallel of a transaction removing a toast value would go through
without that, rather than waiting for the transaction doing the
deletion to commit first.  I have expanded the tests with everything I
could think about, so I'd like to commit the attached.  The test is
fancy with its use of allow_system_table_mods to make the toast
relation names reliable, but it has been really useful.
--
Michael