Michael Paquier <michael.paqu...@gmail.com> writes: > OK, so the problem here is that the relcache, as the syscache, are relying > on SnapshotNow which cannot be used safely as the false index definition > could be read by other backends.
That's one problem. It's definitely not the only one, if we're trying to change an index's definition while an index-accessing operation is in progress. > I assume that the switch phase is not the longest phase of the concurrent > operation, as you also need to build and validate the new index at prior > steps. I am just wondering if it is acceptable to you guys to take a > stronger lock only during this switch phase. We might be forced to fall back on such a solution, but it's pretty undesirable. Even though the exclusive lock would only need to be held for a short time, it can create a big hiccup in processing. The key reason is that once the ex-lock request is queued, it blocks ordinary operations coming in behind it. So effectively it's stopping operations not just for the length of time the lock is *held*, but for the length of time it's *awaited*, which could be quite long. Note that allowing subsequent requests to jump the queue would not be a good fix for this; if you do that, it's likely the ex-lock will never be granted, at least not till the next system idle time. Which if you've got one, you don't need a feature like this at all; you might as well just reindex normally during your idle time. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers