On Sun, Aug 30, 2015 at 6:57 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> But we would still have to deal with the >> fact that unconditional acquire attempt by the backends will cause a vacuum >> to cancel itself, which is undesirable. > > Good point. > >> If we define a new namespace for >> this lock (like the relation extension lock has its own namespace) then >> perhaps the cancellation code could be made to not cancel on that >> condition. But that too seems like a lot of work to backpatch. > > We could possibly teach the autocancel logic to distinguish this lock type > from others without using a new namespace. That seems a bit klugy, but > maybe better than adding a new namespace. (For example, there are > probably only a couple of modes in which we take page-level locks at > present. Choosing a currently unused, but self-exclusive, mode for taking > such a lock might serve.)
That seems like a pretty big kludge to me; it will work until it doesn't.
Adding a new lock type (similar to "relation extension") would address a lot of my concern with the heavyweight lock approach. It strikes me that trying to grab a lock on the index in what's basically a pretty low-level operation here could have a variety of unintended consequences. The autovacuum thing is one; but consider also the risk of new deadlock scenarios resulting from a lock upgrade. Those deadlocks would likely be, to use Peter Geoghegan's term, unprincipled. The locking regime around indexes is already pretty complicated, and I'm skeptical about the idea that we can complicate it further without any blowback.
Is the locking around indexes summarized someplace? About the best thing I could come up with was to do a "git grep LockRelat" and then look for lines where the first argument had a name that seemed likely to refer to an index.
