On Fri, Nov 13, 2020 at 12:11:21PM -0600, Justin Pryzby wrote:
> On Fri, Nov 13, 2020 at 01:39:31PM -0300, Alvaro Herrera wrote:
> > 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?
>
> Your patch didn't actually say "try_relation_open", so didn't work.
> But it does works if I do that, and close the table.
That patch broke the case that a non-index is passed, which I addressed here.
I wondered if the function should return NULL in those cases, but it seems to
be "impossible".
