Neil Conway <[EMAIL PROTECTED]> writes:
> Last year, I questioned why CREATE TRIGGER acquires an
> AccessExclusiveLock on its target table:
> Acquiring an ExclusiveLock should be sufficient: we can safely allow
> concurrent SELECTs on the table.

After re-reading that whole thread, I remain just as uncomfortable as
I was here:

You haven't proposed any use-case at all that justifies taking risks
with insufficient locking of DDL changes.  It's too early in the morning
for me to think of a specific counterexample, but I think the general
line of "TX A starts to work with a table, and then the schema changes
while it's still active" is relevant.  Another problem is that a
transaction that issues CREATE TRIGGER and then some other
schema-changing operation on the same table would likely find itself
trying to upgrade lock from ExclusiveLock to AccessExclusiveLock,
with a very strong chance of deadlock.  This latter scenario seems more
probable to me than the case of "I need to add a trigger while allowing
SELECTs to proceed".

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to