On Tue, Mar 4, 2014 at 10:17 AM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > One possible idea would be to create a new lock level which conflicts > with DDL changes but not with regular operation including dumps; so it > wouldn't self-conflict but it would conflict with ShareUpdateExclusive. > pg_dump would acquire a lock of that level instead of AccessShare; thus > two pg_dumps would be able to run on the same table simultaneously, but > it would block and be blocked by DDL changes that grab SUE. The big > hole in this is that pg_dump would still block vacuum, which is a > problem. I hesitate two suggest two extra levels, one for dumps (which > wouldn't conflict with SUE) and one for non-exclusive DDL changes (which > would.)
AFAIK, the only reason why vacuum takes ShareUpdateExclusive lock is because it can't run at the same time as another vacuum. I tend to think (and have thought for some time) that we really ought to have vacuum take AccessShareLock on the relation plus some other lock that is specific to vacuum (say, a "relation vacuum" lock, just as we have "relation extension" locks). Your idea of a lock strong enough to conflict with DDL but not self-conflicting is interesting, too, but I can't claim to have thought through it all that carefully just yet. I think this is all too late for 9.4, though. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
