Re: Inadequate executor locking of indexes

David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> writes:
> Wrong patch. Here's what I meant to send.

Pushed with some minor tweaking, mostly comments.

Some notes:

* We now have a general convention that queries always take the same lock
type on indexes as on their parent tables, but that convention is not
respected by index DDL. I'm not sure if there is any additional cleanup
that should be done there. The DDL code intends to block concurrent
execution of other DDL on the same index, in most cases, so it may be
fine. At the very least, the different lock levels for those cases are
clearly intentional, while I don't think that was true for DML.

* I dropped the extra assertion you'd added to infer_arbiter_indexes,
as it didn't seem necessary or appropriate. That function's just
interested in inspecting the index, so it doesn't need to assume anything
about how strong the lock is. I think the comment that was there was
just trying to justify the shortcut of hard-wiring the lock level as
RowExclusiveLock.

* I went ahead and changed gin_clean_pending_list() to take
RowExclusiveLock not AccessShareLock on its target index. I'm not quite
sure that AccessShareLock is an actual bug there; it may be that GIN's
internal conventions are such that that's safe. But it sure seemed darn
peculiar, and at risk of causing future problems.

regards, tom lane