Re: BUG #17268: Possible corruption in toast index after reindex index concurrently - Mailing list pgsql-bugs

From Michael Paquier
Subject Re: BUG #17268: Possible corruption in toast index after reindex index concurrently
Date
Msg-id YbAdBT749O7ylwGS@paquier.xyz
Whole thread Raw
In response to Re: BUG #17268: Possible corruption in toast index after reindex index concurrently  ("Bossart, Nathan" <bossartn@amazon.com>)
Responses Re: BUG #17268: Possible corruption in toast index after reindex index concurrently  ("Bossart, Nathan" <bossartn@amazon.com>)
List 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

Attachment

pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #17325: Unexpected streaming replication protocol bytes for IDENTIFY_SYSTEM command
Next
From: Jose Diaz
Date:
Subject: FATAL: postmaster became multithreaded during startup