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
