Re: ALTER TABLE lock strength reduction patch is unsafe

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

In response to

Browse pgsql-hackers by date

  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)