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-12-01 18:46:41
Message-ID: 20201201184641.GD24052@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2020-12-01 18:57:24 Re: error_severity of brin work item
Previous Message David G. Johnston 2020-12-01 18:44:40 Off-Schedule Minor Release Consideration?