On 2020-Nov-30, Justin Pryzby wrote:
> On Mon, Nov 30, 2020 at 08:47:32PM -0300, Alvaro Herrera wrote:
> > The more I look at this, the less I like it. This would set a precedent
> > that any action that can be initiated from an autovac work-item has a
> > requirement of silently being discarded when it referenced a
> > non-existant relation.
>
> My original request was to change to INFO, which is what vacuum proper does at
> vacuum_open_relation(). I realize that still means that new work item handlers
> would have to do the LockOid, try_open dance - maybe it could be factored out.
As I understand, INFO is not well suited to messages that are not going
to the client. Anyway, my point is about the contortions that are
needed to support the case, rather than what exactly do we do when it
happens.
Retrospectively, it's strange that this problem (what happens when
indexes with pending work-items are dropped) hadn't manifested. It
seems a pretty obvious one.
> > I'd rather have the code that drops the index go through the list of
> > work-items and delete those that reference that relation.
> >
> > I'm not sure if this is something that ought to be done in index_drop();
> > One objection might be that if the drop is rolled back, the work-items
> > are lost.
>
> 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.)
