Re: error_severity of brin work item - Mailing list pgsql-hackers

From Justin Pryzby
Subject Re: error_severity of brin work item
Date
Msg-id 20201201184641.GD24052@telsasoft.com
Whole thread Raw
In response to Re: error_severity of brin work item  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: error_severity of brin work item
List pgsql-hackers
On Tue, Dec 01, 2020 at 11:07:30AM -0300, Alvaro Herrera wrote:
> > Should it be done in an AtCommit hook or something like that ?
> 
> I didn't like this idea much on first read, on extensibility grounds,
> but perhaps it's not so bad because we can generalize it whenever
> there's pressure to add a second type of work-item (*if* that ever
> happens).
> 
> I suppose the idea is that index_drop saves the index OID when a BRIN
> index with autosummarization=on is dropped, and then the
> AtCommit_WorkItems() call scans the items list and drops those that
> match any OIDs in the list.  (It does require to be mindful of subxact
> aborts, of course.)

This was an idea I made up - I don't know any of the details of this, but if
you give a hint I could look at it more.  There'd (still) be a race window, but
I think that's ok.

Another idea is if perform_work_item() were responsible for discarding
relations which disappear.  Currently it does this, which is racy since it
holds no lock.

        cur_relname = get_rel_name(workitem->avw_relation);
        cur_nspname = get_namespace_name(get_rel_namespace(workitem->avw_relation));
        cur_datname = get_database_name(MyDatabaseId);
        if (!cur_relname || !cur_nspname || !cur_datname)
                goto deleted2;

-- 
Justin



pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Off-Schedule Minor Release Consideration?
Next
From: Alvaro Herrera
Date:
Subject: Re: error_severity of brin work item