ALTER TABLE ... DISABLE TRIGGER vs. AccessExclusiveLock - Mailing list pgsql-hackers

From James Robinson
Subject ALTER TABLE ... DISABLE TRIGGER vs. AccessExclusiveLock
Date
Msg-id 3A53054C-E654-4E18-9F5E-07B313029910@socialserve.com
Whole thread Raw
Responses Re: ALTER TABLE ... DISABLE TRIGGER vs. AccessExclusiveLock
List pgsql-hackers
Hackers,

Experience and a read through backend/commands/tablecmds.c's  
AlterTable() indicate that ALTER TABLE ... DISABLE TRIGGER obtains an  
exclusive lock on the table (as does any ALTER TABLE).

Blocking other readers from a table when we've, within the body of a  
transaction performing a bulk update operation where we don't want /  
need triggers to fire, seems at first glance to be over-kill. I can  
see how AlterTable()'s complex logic is made less complex through 'get  
and keep a big lock', since most of its operational modes really do  
need exclusive access, but is it strictly required for ... DISABLE /  
REENABLE TRIGGER?

Could, say, RowExclusiveLock hypothetically provide adequate  
protection, allowing concurrent reads, but blocking out any other  
writers (for ENABLE / DISABLE TRIGGER) -- such as if driven through a  
new statement other than ALTER TABLE -- such as "DISABLE TRIGGER foo  
ON tbar" ?

Thanks!
----
James Robinson
Socialserve.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: git config user.email
Next
From: Robert Haas
Date:
Subject: Re: do we need to postpone beta4?