Horton

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

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Noah Misch <noah@leadboat.com>
Cc: 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>, Michael Paquier <michael@paquier.xyz>
Date: 2021-11-09T04:37:58Z
Lists: pgsql-bugs 
Hi, 

On November 8, 2021 7:56:24 PM PST, Noah Misch <noah@leadboat.com> wrote:
>On Mon, Nov 08, 2021 at 12:36:41PM -0800, Andres Freund wrote:
>> One possible way to fix this would be to make ReindexRelationConcurrently()
>> acquire a lock on the underlying table when reindexing a toast table. Another
>> to not release the lock in toast_save_datum().
>
>The latter is more future-proof.  Does it have material disadvantages?

I don't immediately see any. But I've been long of the opinion, and had plenty discussions around it, that our habit of releasing locks early is far too widely used.

I do however wonder if there's other path to the problem, besides saving toast datums. We also release those locks early in other places, and while e.g. r/o locks won't cause a problem with this specific interlock, it could cause problem around dropping the relation, for example.

Andres
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Commits

  1. Fix corruption of toast indexes with REINDEX CONCURRENTLY