13.11.2014, 23:50, Andres Freund kirjoitti: > On November 13, 2014 10:23:41 PM CET, Peter Eisentraut <pete...@gmx.net> > wrote: >> On 11/12/14 7:31 PM, Andres Freund wrote: >>> Yes, it sucks. But it beats not being able to reindex a relation with >> a >>> primary key (referenced by a fkey) without waiting several hours by a >>> couple magnitudes. And that's the current situation. >> >> That's fine, but we have, for better or worse, defined CONCURRENTLY := >> does not take exclusive locks. Use a different adverb for an >> in-between >> facility. > > I think that's not actually a service to our users. They'll have to adapt > their scripts and knowledge when we get around to the more concurrent > version. What exactly CONCURRENTLY means is already not strictly defined and > differs between the actions. > > I'll note that DROP INDEX CONCURRENTLY actually already internally acquires > an AEL lock. Although it's a bit harder to see the consequences of that.
If the short-lived lock is the only blocker for this feature at the moment could we just require an additional qualifier for CONCURRENTLY (FORCE?) until the lock can be removed, something like: tmp# REINDEX INDEX CONCURRENTLY tmp_pkey; ERROR: REINDEX INDEX CONCURRENTLY is not fully concurrent; use REINDEX INDEX CONCURRENTLY FORCE to perform reindex with a short-lived lock. tmp=# REINDEX INDEX CONCURRENTLY FORCE tmp_pkey; REINDEX It's not optimal, but currently there's no way to reindex a primary key anywhere close to concurrently and a short lock would be a huge improvement over the current situation. / Oskari -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
