Re: Reducing Catalog Locking
От | Andres Freund |
---|---|
Тема | Re: Reducing Catalog Locking |
Дата | |
Msg-id | 20141031135421.GH13584@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: Reducing Catalog Locking (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Reducing Catalog Locking
Re: Reducing Catalog Locking |
Список | pgsql-hackers |
On 2014-10-31 09:48:52 -0400, Tom Lane wrote: > Robert Haas <robertmhaas@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
В списке pgsql-hackers по дате отправления: