Re: Dropping behavior for unique CONSTRAINTs - Mailing list pgsql-general

From Conner Bean
Subject Re: Dropping behavior for unique CONSTRAINTs
Date
Msg-id d9ab5280-2aff-4265-8f7b-0cdcca836d17@me.com
Whole thread Raw
In response to Re: Dropping behavior for unique CONSTRAINTs  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-general
Ah, my apologies for missing that in the docs. I had previously noticed the CONCURRENTLY option on drop index, but I misread and incorrectly thought that unique indexes themselves could not be dropped concurrently, rather than that being true for only unique indexes backing constraints. Apologies on my misunderstanding!

Thanks greatly for your help!

Best,
CSB

On Mar 3, 2023, at 5:54 AM, David Rowley <dgrowleyml@gmail.com> wrote:


On Fri, 3 Mar 2023 at 23:17, Conner Bean <conner.bean@icloud.com> wrote:
I wanted to avoid using a unique index since dropping them requires an
exclusive lock and cannot be done concurrently. My thought was to then
use a unique constraint, since I've read unofficial docs[0] that say
these can be dropped safely with no lock.

You should try the official documents. You won't find any wording in
those that say that a unique constraint can be dropped without any
locking.

you'll see "Note that the lock level required may differ for each
subform. An ACCESS EXCLUSIVE lock is acquired unless explicitly
noted.", and if you look at DROP CONSTRAINT that it mentions nothing
about any lower-level locks, so you can assume that DROP CONSTRAINT
obtains an access exclusive lock on the table being altered.

If you have a look at
CONCURRENTLY option. That option allows an index to be dropped without
blocking concurrent reads and writes to the table. It seems like just
having a unique index without the constraint is likely your best bet
if you can't afford to block any traffic for the brief moment it would
take to drop the constraint.

David


pgsql-general by date:

Previous
From: Simon Elbaz
Date:
Subject: Re: PG16devel - vacuum_freeze_table_age seems not being taken into account
Next
From: Peter Geoghegan
Date:
Subject: Re: PG16devel - vacuum_freeze_table_age seems not being taken into account