On 10/1/14 3:00 AM, Michael Paquier wrote: > - Use of AccessExclusiveLock when swapping relfilenodes of an index and > its concurrent entry instead of ShareUpdateExclusiveLock for safety. At > the limit of my understanding, that's the consensus reached until now.
I'm very curious about this point. I looked through all the previous discussions, and the only time I saw this mentioned was at the very beginning when it was said that we could review the patch while ignoring this issue and fix it later with MVCC catalog access. Then it got very technical, but it was never explicitly concluded whether it was possible to fix this or not. Also, in the thread "Concurrently option for reindexdb" you pointed out that requiring an exclusive lock isn't really concurrent and proposed an option like --minimum-locks. I will point out again that we specifically invented DROP INDEX CONCURRENTLY because holding an exclusive lock even briefly isn't good enough. If REINDEX cannot work without an exclusive lock, we should invent some other qualifier, like WITH FEWER LOCKS. It's still useful, but we shouldn't give people the idea that they can throw away their custom CREATE INDEX CONCURRENTLY + DROP INDEX CONCURRENTLY scripts. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
