On 2020-Nov-13, Justin Pryzby wrote:
> I saw a bunch of these in my logs:
>
> log_time | 2020-10-25 22:59:45.619-07
> database |
> left | could not open relation with OID 292103095
> left | processing work entry for relation
> "ts.child.alarms_202010_alarm_clear_time_idx"
>
> Those happen following a REINDEX job on that index.
>
> I think that should be more like an INFO message, since that's what vacuum
> does
> (vacuum_open_relation), and a queued work item is even more likely to hit a
> dropped relation.
Ah, interesting. Yeah, I agree this is a bug. I think it can be fixed
by using try_relation_open() on the index; if that returns NULL, discard
the work item.
Does this patch solve the problem?
diff --git a/src/backend/access/brin/brin.c b/src/backend/access/brin/brin.c
index 1f72562c60..6021b16a01 100644
--- a/src/backend/access/brin/brin.c
+++ b/src/backend/access/brin/brin.c
@@ -887,8 +887,10 @@ brin_summarize_range(PG_FUNCTION_ARGS)
/*
* We must lock table before index to avoid deadlocks. However, if the
* passed indexoid isn't an index then IndexGetRelation() will fail.
- * Rather than emitting a not-very-helpful error message, postpone
- * complaining, expecting that the is-it-an-index test below will fail.
+ * Rather than emitting a not-very-helpful error message, prepare to
+ * return without doing anything. This allows autovacuum work-items to be
+ * silently discarded rather than uselessly accumulating error messages in
+ * the server log.
*/
heapoid = IndexGetRelation(indexoid, true);
if (OidIsValid(heapoid))
@@ -897,6 +899,11 @@ brin_summarize_range(PG_FUNCTION_ARGS)
heapRel = NULL;
indexRel = index_open(indexoid, ShareUpdateExclusiveLock);
+ if (heapRel == NULL || indexRel == NULL)
+ {
+ /* Table or index don't exist anymore; ignore this request */
+ PG_RETURN_INT32(0);
+ }
/* Must be a BRIN index */
if (indexRel->rd_rel->relkind != RELKIND_INDEX ||
