Re: ALTER TABLE lock strength reduction patch is unsafe
От | Simon Riggs |
---|---|
Тема | Re: ALTER TABLE lock strength reduction patch is unsafe |
Дата | |
Msg-id | CA+U5nMLVXmqZ9hNXbUDTnqouJPEdD7p9n-fd6cJC9TqqWL-k7w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: ALTER TABLE lock strength reduction patch is unsafe (Atri Sharma <atri.jiit@gmail.com>) |
Ответы |
Re: ALTER TABLE lock strength reduction patch is unsafe
Re: ALTER TABLE lock strength reduction patch is unsafe |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: