On 2014-10-31 10:02:28 -0400, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2014-10-31 09:48:52 -0400, Tom Lane wrote:
> >> 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.
>
> I lack adequate caffeine at the moment, so explain to me how this adds
> any guarantees whatsoever? It sounded like only a performance
> optimization from here.
A performance optimization might be what Simon intended, but it isn't
primarily what I (and presumably Robert) thought it be useful for.
Consider the example in
http://archives.postgresql.org/message-id/20130507141526.GA6117%40awork2.anarazel.de
If pg_dump were to take the 'ddl lock' *before* acquiring the snapshot
to lock all tables, that scenario couldn't happen anymore. As soon as
pg_dump has acquired the actual locks the ddl lock could be released
again.
Taking the ddl lock from SQL would probably require some 'backup' or
superuser permission, but luckily there seems to be movement around
that.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services