agora inbox for pgsql-bugs@postgresql.org
help / color / mirror / Atom feedFrom: Álvaro Herrera <alvherre@kurilemu.de>
To: Robert Treat <rob@xzilla.net>
Cc: shihao zhong <zhong950419@gmail.com>
Cc: Zsolt Parragi <zsolt.parragi@percona.com>
Cc: Christophe Pettus <xof@thebuild.com>
Cc: pgsql-hackers@lists.postgresql.org, Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: rmt@lists.postgresql.org
Subject: Re: REPACK (CONCURRENTLY) doesn't handle invalid indexes
Date: Tue, 15 Sep 2026 17:30:54 +0200
Message-ID: <aqkXyUZFk__dKqvm@alvherre.pgsql> (raw)
In-Reply-To: <CABV9wwOfL+5YfCK8mKzgerQKFPuLPgHg8Arsqp0nDTzP6ug0Dg@mail.gmail.com>
On 2026-Sep-14, Robert Treat wrote:
> The patch looks right to me, and I think I am +1 for this generally,
> though I would note that we are widening the scope here such that
> indexes that could succeed with a rebuild would now cause an error, so
> we're a little less functional though a little more behaviorally
> consistent.
Yeah. I considered the idea of adding a REPACK option like
"rebuild_invalid_indexes=on" that would attempt to rebuild rather than
failing outright, at the user's risk. Not sure it's worth the trouble.
I have pushed this change now, without the test. I did throw in a short
doc update.
One thing I didn't want to say in said doc update, is that while you can
do a REINDEX of the non-validated index prior to REPACK, it's rather a
complete waste of time, because REPACK has to rebuild that index again.
It's probably better to DROP the index, then REPACK, then do CREATE
INDEX CONCURRENTLY. If we didn't cause REPACK to error out in the
presence of a buildable invalid index, then REPACK could rebuild the
index just fine. I'm happy to listen to your operationally-experienced
opinion on this.
> This does feel hacky, since we're being manipulative rather than
> testing a real scenario.
Yeah.
> I think what we want would be to follow the lead of
> src/test/modules/injection_points/sql/reindex_conc.sql?
Do you mean creating test invalid indexes by way of using injection
points to interrupt creation in the various phases? I don't see
reindex_conc.sql doing that. But also, we run these tests in
test_decoding because it's the test suite that is certain to have
wal_level=logical; but if we wanted to also require injection_points,
the changes in meson.build / Makefile get more involved. I didn't find
a test suite that has conditional tests depending on injection_points.
src/test/modules/authentication does, but for a TAP test, not a plain
regress or isolation test. It is surely just a SMOP ...
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
“Cuando no hay humildad las personas se degradan” (A. Christie)
view thread (21+ messages) latest in thread
Message-ID: <aqkXyUZFk__dKqvm@alvherre.pgsql>
Permalink: ../aqkXyUZFk__dKqvm@alvherre.pgsql/
Also on: postgresql.org/message-id/aqkXyUZFk__dKqvm@alvherre.pgsql
reply
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: alvherre@kurilemu.de, rob@xzilla.net, zhong950419@gmail.com, zsolt.parragi@percona.com, xof@thebuild.com, horikyota.ntt@gmail.com, rmt@lists.postgresql.org
Subject: Re: REPACK (CONCURRENTLY) doesn't handle invalid indexes
In-Reply-To: <aqkXyUZFk__dKqvm@alvherre.pgsql>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox