On Tue, Sep 1, 2015 at 8:05 AM, Robert Haas <robertmh...@gmail.com> wrote:
> On Sun, Aug 30, 2015 at 6:57 PM, Tom Lane <t...@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. Cheers, Jeff
