Re: ALTER TABLE lock strength reduction patch is unsafe

Поиск
Список
Период
Сортировка
От Atri Sharma
Тема Re: ALTER TABLE lock strength reduction patch is unsafe
Дата
Msg-id CAOeZVifePi5ZcoRZPNO3jh=BkrfCYepQwDdgsa1RsSKUp9QEyA@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  (Simon Riggs <simon@2ndQuadrant.com>)
Re: ALTER TABLE lock strength reduction patch is unsafe  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers


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.

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.

I am not too comfortable with exposing the locking type to the user. That may be just me though.

Regards,

Atri
--
Regards,
 
Atri
l'apprenant

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: jsonb and nested hstore
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Patch: show relation and tuple infos of a lock to acquire