>> Postgres is currently full of fairly innocent-looking commands which >> take an unexpected ACCESS EXCLUSIVE lock. For example, DROP CONSTRAINT >> takes an accessexclusive lock, but it hasn't stopped people from using >> constraints, and isn't particularly high up on our todo list to fix >> it. > > Thats a pretty unconvincing comparison. There isn't any expectation that > ALTER TABLE works without taking exlusive locks from common
Not exclusive (which is expected), but AccessExclusive (which catches many of our users by surprise). How about the fact that dropping an FK constraint takes an AccessExclusiveLock on the *referenced* table? > implementations and DROP CONSTRAINT only takes a very short time while > refreshing a materialized view possibly take rather long. Right now there's no expectations at all about our new Matview feature. I think putting the locking information in the docs is the right way to go. > Thats scaring me. Because the current state of the feature isn't > something that people expect under the term "materialized views" and I > am pretty damn sure people will then remember postgres as trying to > provide a tick-box item without it being really usable in the real > world. > And thats not something I want postgres to be known for. We promoted the heck out of binary replication when it was barely usable. We've gotten huge interest in our JSON support, even when it's a work-in-progress. I don't see why I should change an approach to advocacy which is clearly working. What our project considers an incomplete feature other OSS DBMSes call a version 2.0. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
