From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Peter Geoghegan <pg(at)heroku(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: ALTER TABLE lock strength reduction patch is unsafe |
Date: | 2014-02-27 08:06:32 |
Message-ID: | CA+U5nM+cZ1HPAOL1C5GVK3dyJVdhBvJDiJ9E+axBDyJv0V8bvg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 26 February 2014 07:32, Simon Riggs <simon(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Christian Kruse | 2014-02-27 08:08:33 | Re: [PATCH] Use MAP_HUGETLB where supported (v3) |
Previous Message | Christian Kruse | 2014-02-27 07:35:32 | Re: [PATCH] Use MAP_HUGETLB where supported (v3) |