Horton

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

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: "Bossart, Nathan" <bossartn@amazon.com>
Cc: Noah Misch <noah@leadboat.com>, Andres Freund <andres@anarazel.de>, Alexey Ermakov <alexey.ermakov@dataegret.com>, Robert Haas <robertmhaas@gmail.com>, Maxim Boguk <maxim.boguk@gmail.com>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>, Peter Geoghegan <pg@bowt.ie>
Date: 2021-12-08T02:48:37Z
Lists: pgsql-bugs 
On Tue, Dec 07, 2021 at 10:04:54PM +0000, Bossart, Nathan wrote:
> I confirmed that the new tests reliably produce corruption and that
> the suggested fix resolves it.  I also lean towards the simple
> solution, but I do wonder if it creates any interesting side effects.

Thanks.

> For example, could holding the locks longer impact performance?

Do you have anything particular in mind?  It seems to me that this
boils down to the same lock taken on the parent table based on its
RTE.

> -	toast_close_indexes(toastidxs, num_indexes, RowExclusiveLock);
> -	table_close(toastrel, RowExclusiveLock);
> +	toast_close_indexes(toastidxs, num_indexes, NoLock);
> +	table_close(toastrel, NoLock);
> 
> I think it would be good to expand the comments above these changes to
> explain why we are keeping the lock.  That might help avoid similar
> problems in the future.

Yes, I have added a note, and applied the patch after looking at it
again this morning.  The test cannot be used in 12 so I have removed
it from REL_12_STABLE, as allow_system_table_mods is a PGC_POSTMASTER
there.
--
Michael

Commits

  1. Fix corruption of toast indexes with REINDEX CONCURRENTLY