On 2014-11-12 16:11:58 -0500, Robert Haas wrote: > On Wed, Nov 12, 2014 at 4:10 PM, Robert Haas <robertmh...@gmail.com> wrote: > > On Thu, Nov 6, 2014 at 9:50 AM, Peter Eisentraut <pete...@gmx.net> wrote: > >> If REINDEX cannot work without an exclusive lock, we should invent some > >> other qualifier, like WITH FEWER LOCKS. > > > > What he said.
I'm unconvinced. A *short* exclusive lock (just to update two pg_class row), still gives most of the benefits of CONCURRENTLY. Also, I do think we can get rid of that period in the not too far away future. > But more to the point .... why, precisely, can't this work without an > AccessExclusiveLock? And can't we fix that instead of setting for > something clearly inferior? It's nontrivial to fix, but I think we can fix it at some point. I just think we should get the *major* part of the feature before investing lots of time making it even better. There's *very* frequent questions about having this. And people do really dangerous stuff (like manually updating pg_class.relfilenode and such) to cope. The problem is that it's very hard to avoid the wrong index's relfilenode being used when swapping the relfilenodes between two indexes. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
