On 4 March 2014 01:07, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2014-03-03 19:15:27 -0500, Tom Lane wrote:
>> Noah Misch <noah@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.
Good points.
In most cases, DDL is applied manually after careful thought, so
people seldom dump at the same time they upgrade the database. This is
especially true for pg_dump since it captures the logical definition
of tables. So most people will be happy with the default locking, but
we could make the lock level optional.
Currently we use AccessShareLock. Locking out all DDL, even with this
patch applied would only require ShareUpdateExclusiveLock.
Looking at the code, it will take about an hour to add an option to
pg_dump that specifies the lock level used when dumping. I would be
happy to include that as part of this patch.
-- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services