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)")
Date: Sun, 16 Jun 2024 18:52:52 -0400
Message-ID: <3045795.1718578372@sss.pgh.pa.us> (raw)
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18499: Reindexing spgist index concurrently triggers Assert("TransactionIdIsValid(state->myXid)")
In-Reply-To: <3045795.1718578372@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox