Re: ALTER TABLE lock strength reduction patch is unsafe
От | Simon Riggs |
---|---|
Тема | Re: ALTER TABLE lock strength reduction patch is unsafe |
Дата | |
Msg-id | CA+U5nM+cZ1HPAOL1C5GVK3dyJVdhBvJDiJ9E+axBDyJv0V8bvg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: ALTER TABLE lock strength reduction patch is unsafe (Simon Riggs <simon@2ndQuadrant.com>) |
Список | pgsql-hackers |
On 26 February 2014 07:32, Simon Riggs <simon@2ndquadrant.com> wrote: >> * Are you sure AlterConstraint is generally safe without an AEL? It >> should be safe to change whether something is deferred, but not >> necessarily whether it's deferrable? > > We change the lock levels for individual commands. This patch provides > some initial settings and infrastructure. > > It is possible you are correct that changing the deferrability is not > safe without an AEL. That was enabled for the first time in this > release in a patch added by me after this patch was written. I will > think on that and change, if required. Thoughts... It would be a problem to change a DEFERRABLE constraint into a NOT DEFERRABLE constraint concurrently with a transaction that was currently deferring its constraint checks. It would not be a problem to go in the other direction, relaxing the constraint attributes. The patch uses ShareRowExclusive for AlterConstraint, so no writes are possible concurrently with the table being ALTERed, hence the problem situation cannot arise. So in my understanding, no issue is possible. -- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: