On 2014-03-03 19:15:27 -0500, Tom Lane wrote: > Noah Misch <n...@leadboat.com> writes: > > Just to be clear, that list is not a commentary on the particular patch at > > hand. Those are merely the kinds of regressions to look for in a patch > > affecting this area of the code. > > A complaint on pgsql-bugs just now reminded me of a specific area that > needs to be looked at hard: how bad are the implications for pg_dump? > > Up to now, pg_dump could be reasonably confident that once it had > AccessShareLock on every table it intended to dump, there would be no > schema changes happening on those tables until it got done.
The guarantee wasn't actually that strong. It already was quite possible that indexes got created/dropped during that time, which probably is the by far most frequent DDL run in production. > This greatly > ameliorates the snapshot-skew problems that arise from its habit of doing > some things for itself and other things via backend-internal functions > (which historically used SnapshotNow and now use a fresh MVCC snapshot, > either way potentially quite newer than the transaction snapshot pg_dump's > own queries will use). Yea, I wonder if we shouldn't start to make them use a different snapshot. It's the pg_get_*def() functions, or is there something else? Afair (I really haven't rechecked) all the actions that have a changed locklevels affect things that pg_dump recreates clientside, using a repeatable read snapshot, so there shouldn't be much change there? 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
