Re: error_severity of brin work item

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: error_severity of brin work item
Date: 2020-11-19 17:38:48
Message-ID: 20201119173848.GU24784@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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".

Attachment Content-Type Size
v3-0001-Avoid-errors-in-brin-summarization.patch text/x-diff 2.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Surafel Temesgen 2020-11-19 18:03:50 Re: WIP: System Versioned Temporal Table
Previous Message Tels 2020-11-19 17:19:44 Re: Tab complete for CREATE OR REPLACE TRIGGER statement