database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2026-10-23 13:29:09 +03:00
Code Activity

Fail REPACK in presence of invalid indexes, take 2

Browse Source 
Commit 0c5d626961 was confused about which indexes are potentially
problematic to rebuild: we thought only !indisready indexes could fail
to rebuild, and thus would attempt to rebuild !indisvalid ones that are
"ready" (that is, being maintained by DML but not yet completed).
However, that's wrong, because it could be that the validation phase of
such an index failed or was interrupted partway through.  So, have
REPACK throw an error with all !indisvalid indexes, not just those
!indisready.

(!indisready implies !indisvalid, so this is an expansion of what
happened with the previous commit.)

Reported-by: shihao zhong <zhong950419@gmail.com>
Backpatch-through: 19
Discussion: https://postgr.es/m/CAGRkXqRA4YetT8Nu3+1-45+ffTwi2bd1d1eDFME39Y9OPRMytQ@mail.gmail.com
This commit is contained in:
Álvaro Herrera
2026-09-15 15:40:59 +02:00
parent ddce1da5b1
commit 78142821df
2 changed files with 14 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
doc/src/sgml/ref/repack.sgml
View File

@@ -384,6 +384,12 @@ REPACK [ ( <replaceable class="parameter">option</replaceable> [, ...] ) ] USING
on the table.
</para>
<para>
<command>REPACK</command> refuses to process a table on which an invalid
index exists. Such indexes must be dropped or reindexed by the user ahead
of time.
</para>
<para>
While <command>REPACK</command> is running, the <xref
linkend="guc-search-path"/> is temporarily changed to <literal>pg_catalog,

15
src/backend/commands/repack.c
View File

@@ -886,13 +886,15 @@ mark_index_clustered(Relation rel, Oid indexOid, bool is_internal)
/*
* check_index_requirements: verify index state on relation being processed
*
* Throw an error if any !indisready indexes are found.
* Throw an error if any incompletely-built indexes are found.
*
* Indexes that are not ready for inserts, such as ones left behind by failed
* CREATE INDEX CONCURRENTLY, are not maintained by DML. In some cases they
* may fail to build altogether. Throwing an error here forces the user to
* take action on these indexes separately from the table reconstruction,
* which prevents perpetuating them for no reason.
* CREATE INDEX CONCURRENTLY, are not maintained by DML. Indexes that aren't
* marked valid could have been in the middle of validation when their build
* failed, and thus it's not certain that they could be built. In both cases,
* attempting to rebuild may fail altogether. Throwing an error here forces
* the user to take action on these indexes separately from the table
* reconstruction, which prevents perpetuating them for no reason.
*/
static void
check_index_requirements(Relation rel, RepackCommand cmd)
@@ -920,9 +922,8 @@ check_index_requirements(Relation rel, RepackCommand cmd)
{
Form_pg_index index = (Form_pg_index) GETSTRUCT(htup);
if (!index->indisready)
if (!index->indisvalid)
{
Assert(!index->indisvalid);
if (num_invalid_idxs == 0)
appendStringInfo(&dest, _("\"%s\""), get_rel_name(index->indexrelid));
else