postgres.git / summary / log / commit / refs

commit    43cca9de9a0adf3fb47aaa6310cc0022a78eee8a
Author:   Tom Lane <tgl@sss.pgh.pa.us>
Date:     Sun Feb 25 21:15:07 2024 +0000
First released in: 17.0, 12.19, 13.15, 14.12, 15.7, 16.3

    Promote assertion about !ReindexIsProcessingIndex to runtime error.
    
    When this assertion was installed (in commit d2f60a3ab), I thought
    it was only for catching server logic errors that caused accesses to
    catalogs that were undergoing index rebuilds.  However, it will also
    fire in case of a user-defined index expression that attempts to
    access its own table.  We occasionally see reports of people trying
    to do that, and typically getting unintelligible low-level errors
    as a result.  We can provide a more on-point message by making this
    a regular runtime check.
    
    While at it, adjust the similar error check in
    systable_beginscan_ordered to use the same message text.  That one
    is (probably) not reachable without a coding bug, but we might as
    well use a translatable message if we have one.
    
    Per bug #18363 from Alexander Lakhin.  Back-patch to all supported
    branches.
    
    Discussion: https://postgr.es/m/18363-e3598a5a572d0699@postgresql.org


 src/backend/access/index/genam.c   |  6 ++++--
 src/backend/access/index/indexam.c | 17 +++++++++++------
 2 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/src/backend/access/index/genam.c b/src/backend/access/index/genam.c
index dfba5ae39ae..40bb273cf58 100644
--- a/src/backend/access/index/genam.c
+++ b/src/backend/access/index/genam.c
@@ -576,8 +576,10 @@ systable_beginscan_ordered(Relation heapRelation,
 
 	/* REINDEX can probably be a hard error here ... */
 	if (ReindexIsProcessingIndex(RelationGetRelid(indexRelation)))
-		elog(ERROR, "cannot do ordered scan on index \"%s\", because it is being reindexed",
-			 RelationGetRelationName(indexRelation));
+		ereport(ERROR,
+				(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+				 errmsg("cannot access index \"%s\" while it is being reindexed",
+						RelationGetRelationName(indexRelation))));
 	/* ... but we only throw a warning about violating IgnoreSystemIndexes */
 	if (IgnoreSystemIndexes)
 		elog(WARNING, "using index \"%s\" despite IgnoreSystemIndexes",
diff --git a/src/backend/access/index/indexam.c b/src/backend/access/index/indexam.c
index 6b9750c244a..6210c3781ca 100644
--- a/src/backend/access/index/indexam.c
+++ b/src/backend/access/index/indexam.c
@@ -70,18 +70,23 @@
  * Note: the ReindexIsProcessingIndex() check in RELATION_CHECKS is there
  * to check that we don't try to scan or do retail insertions into an index
  * that is currently being rebuilt or pending rebuild.  This helps to catch
- * things that don't work when reindexing system catalogs.  The assertion
+ * things that don't work when reindexing system catalogs, as well as prevent
+ * user errors like index expressions that access their own tables.  The check
  * doesn't prevent the actual rebuild because we don't use RELATION_CHECKS
  * when calling the index AM's ambuild routine, and there is no reason for
  * ambuild to call its subsidiary routines through this file.
  * ----------------------------------------------------------------
  */
 #define RELATION_CHECKS \
-( \
-	AssertMacro(RelationIsValid(indexRelation)), \
-	AssertMacro(PointerIsValid(indexRelation->rd_indam)), \
-	AssertMacro(!ReindexIsProcessingIndex(RelationGetRelid(indexRelation))) \
-)
+do { \
+	Assert(RelationIsValid(indexRelation)); \
+	Assert(PointerIsValid(indexRelation->rd_indam)); \
+	if (unlikely(ReindexIsProcessingIndex(RelationGetRelid(indexRelation)))) \
+		ereport(ERROR, \
+				(errcode(ERRCODE_FEATURE_NOT_SUPPORTED), \
+				 errmsg("cannot access index \"%s\" while it is being reindexed", \
+						RelationGetRelationName(indexRelation)))); \
+} while(0)
 
 #define SCAN_CHECKS \
 ( \


[parent: 7cbf8d3c5ef9]