Re: error_severity of brin work item
От | Justin Pryzby |
---|---|
Тема | Re: error_severity of brin work item |
Дата | |
Msg-id | 20201119173848.GU24784@telsasoft.com обсуждение исходный текст |
Ответ на | Re: error_severity of brin work item (Justin Pryzby <pryzby@telsasoft.com>) |
Ответы |
Re: error_severity of brin work item
|
Список | pgsql-hackers |
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".
Вложения
В списке pgsql-hackers по дате отправления: