On 4 March 2014 09:31, Simon Riggs <si...@2ndquadrant.com> wrote: > 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.
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
