On 4 March 2014 08:39, Atri Sharma <atri.j...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
