From: Tom Lane <tgl@sss.pgh.pa.us>
To: exclusion@gmail.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18499: Reindexing spgist index concurrently triggers
 Assert("TransactionIdIsValid(state->myXid)")
In-reply-to: <3030961.1718570047@sss.pgh.pa.us>
References: <18499-8a519c280f956480@postgresql.org>
 <428421.1717887173@sss.pgh.pa.us> <3030961.1718570047@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Sun, 16 Jun 2024 16:34:07 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3045794.1718578372.1@sss.pgh.pa.us>
Date: Sun, 16 Jun 2024 18:52:52 -0400
Message-ID: <3045795.1718578372@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3045795.1718578372%40sss.pgh.pa.us>
Precedence: bulk

I wrote:
> So I conclude that we basically just need to remove the failing
> assertion in spgFormDeadTuple and instead add a guard for invalid
> xid in vacuumRedirectAndPlaceholder.

BTW, a different line of attack could be to not generate redirects
at all during REINDEX CONCURRENTLY: on the basis of this argument,
we don't need them.  So that would look roughly similar to the tests
that skip making redirects when isBuild is true, and it'd allow
keeping the assertion in spgFormDeadTuple, and it'd save some
usually-trifling amount of work in the next VACUUM.  However, I'm
not sure there's a nice way for spginsert() to know whether it's
being invoked in REINDEX CONCURRENTLY or a normal INSERT/UPDATE
query.  Can we trust indexInfo->ii_Concurrent for that?

			regards, tom lane