On 4 March 2014 09:31, Simon Riggs <simon@2ndquadrant.com> wrote:
> On 4 March 2014 08:39, Atri Sharma <atri.jiit@gmail.com> wrote:
>>
>>>
>>> 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.
>>
>>
>>
>> I think the use case for specifying multiple locks is pretty slim given that
>> a ShareUpdateExclusiveLock is good enough mostly for everybody.
>
> Increasing the lock strength would be a change in behaviour that might
> adversely affect existing users.
The main impact I see is that this would block VACUUM while pg_dump runs.
But then, while pg_dump runs VACUUM is ineffective anyway so perhaps
that is no bad thing.
Autovacuum requests VACOPT_NOWAIT so would skip the relations being
dumped rather than waiting.
-- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services