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.
> If its not the case, the user should be more careful about when he is
> scheduling backups to so that they dont conflict with DDL changes.
That is most certainly the wise choice.
> I am not too comfortable with exposing the locking type to the user. That
> may be just me though.
Why would that be a problem? Hard reasons, please.
-- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services