On 2014-10-31 09:48:52 -0400, Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: > > On a related note, I've previously had the thought that it would be > > nice to have a "big DDL lock" - that is, a lock that prevents > > concurrent DDL without preventing anything else - so that pg_dump > > could get just that one lock and then not worry about the state of the > > world changing under it. > > Hm ... how would that work exactly? Every DDL operation has to take > the BigDDLLock in shared mode, and then pg_dump takes it in exclusive > mode? > > That would preclude two pg_dumps running in parallel, which > maybe isn't a mainstream usage but still there's never been such a > restriction before. Parallel pg_dump might have an issue in particular.
It should probably be a heavyweight lock. Then every DDL operation can take it in RowExclusiveLock mode and pg_dump can take ShareLock. As RowExclusive is a fastpath elegible lock, that'll not even hit the global lock table most of the time. > But more to the point, this seems like optimizing pg_dump startup by > adding overhead everywhere else, which doesn't really sound like a > great tradeoff to me. Well, it'd finally make pg_dump "correct" under concurrent DDL. That's quite a worthwile thing. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
