Re: locks in CREATE TRIGGER, ADD FK - Mailing list pgsql-hackers

From Tom Lane
Subject Re: locks in CREATE TRIGGER, ADD FK
Date
Msg-id 4750.1117420419@sss.pgh.pa.us
Whole thread Raw
In response to Re: locks in CREATE TRIGGER, ADD FK  (Neil Conway <neilc@samurai.com>)
List pgsql-hackers
Neil Conway <neilc@samurai.com> writes:
> Are there any remaining objections to reapplying this patch?
> The original commit message is here:
> http://archives.postgresql.org/pgsql-committers/2005-03/msg00316.php
> The archives of the -hackers thread are here:
> http://archives.postgresql.org/pgsql-hackers/2005-03/msg00764.php

I'm still concerned about the last example I raised in
http://archives.postgresql.org/pgsql-hackers/2005-03/msg00840.php
which was:

>>         Transaction 1           Transaction 2
>> 
>>         BEGIN;
>> 
>>         SELECT FROM a;
>> 
>>         ...                     CREATE TRIGGER ... ON INSERT TO a ...
>> 
>>         INSERT INTO a;
>> 
>> Ordinarily, once T1 has touched relation A, it can be sure that A's
>> schema will not change until end of transaction.  The change you
>> committed last night removes that guarantee, at least for the
>> limited case of triggers, and makes the above interleaving possible.
>> While I haven't come up with a clear failure case after a few minutes'
>> thought, I'm not convinced that there isn't one.

It's possible that this is safe for triggers only, but I'm not 100%
convinced of that, and I'm not sure I see the point of relaxing the
general rule "schema changes require AccessExclusiveLock" for just
this one operation.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Neil Conway
Date:
Subject: Re: locks in CREATE TRIGGER, ADD FK
Next
From: Bruce Momjian
Date:
Subject: Re: Escape handling in COPY, strings, psql