error_severity of brin work item - Mailing list pgsql-hackers

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.  It's easy to hit by setting autovacuum_naptime=1 and looping
around REINDEX CONCURRENTLY while updating a table.

Autovacuum is queueing work items for later:

src/backend/postmaster/autovacuum.c-            switch (workitem->avw_type)
src/backend/postmaster/autovacuum.c-            {
src/backend/postmaster/autovacuum.c-                    case AVW_BRINSummarizeRange:
src/backend/postmaster/autovacuum.c:                            DirectFunctionCall2(brin_summarize_range,
src/backend/postmaster/autovacuum.c-
ObjectIdGetDatum(workitem->avw_relation),
src/backend/postmaster/autovacuum.c-
Int64GetDatum((int64)workitem->avw_blockNumber));
 
src/backend/postmaster/autovacuum.c-                            break;

And if the index is missing:

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.
|         */
|        heapoid = IndexGetRelation(indexoid, true);
|        if (OidIsValid(heapoid))
|                heapRel = table_open(heapoid, ShareUpdateExclusiveLock);
|        else
|                heapRel = NULL;
|
|        indexRel = index_open(indexoid, ShareUpdateExclusiveLock);

table_open is succcessful and then index_open fails.  (I thought locks would
have prevented that ?)

Justin