error_severity of brin work item

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