Re: ALTER TABLE lock strength reduction patch is unsafe
От | Simon Riggs |
---|---|
Тема | Re: ALTER TABLE lock strength reduction patch is unsafe |
Дата | |
Msg-id | CA+U5nMLWX7Xa-segLxr9j8yf=nMXjCKN6Ty2joSZ_SxL-Q-DXw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: ALTER TABLE lock strength reduction patch is unsafe (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: ALTER TABLE lock strength reduction patch is unsafe
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: