From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
cc: richard.vesely@softea.sk, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18016: REINDEX TABLE failure
In-reply-to: <ZKirERBzkM48E0op@paquier.xyz>
References: <18016-2bd9b549b1fe49b3@postgresql.org>
 <ZKirERBzkM48E0op@paquier.xyz>
Comments: In-reply-to Michael Paquier <michael@paquier.xyz>
	message dated "Sat, 08 Jul 2023 09:17:21 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1457240.1688775601.1@sss.pgh.pa.us>
Date: Fri, 07 Jul 2023 20:20:01 -0400
Message-ID: <1457241.1688775601@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1457241.1688775601%40sss.pgh.pa.us>
Precedence: bulk

Michael Paquier <michael@paquier.xyz> writes:
> On Thu, Jul 06, 2023 at 08:29:19PM +0000, PG Bug reporting form wrote:
>> Given a table with a TOASTed variable length attribute, REINDEX TABLE fails
>> to rebuild indexes when you truncate (or otherwise corrupt) relation files
>> for both TOAST table index and a custom index on the varlena.

> Could you clarify what you have done here?  Did you manipulate the
> physical files in the data folder before running the REINDEX commands
> you expected should work?  There are many things that can go wrong if
> you do anything like that.

I think the point of that was just to have a way to reproduce the problem
on-demand.  I follow the argument, which is that if there's actual
corruption in the TOAST index (for whatever reason) that might interfere
with rebuilding the table's other indexes.

			regards, tom lane