From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Neil Conway <neilc(at)samurai(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: locks in CREATE TRIGGER, ADD FK |
Date: | 2005-05-30 02:33:39 |
Message-ID: | 4750.1117420419@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Neil Conway <neilc(at)samurai(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2005-05-30 03:50:53 | Re: Escape handling in COPY, strings, psql |
Previous Message | ITAGAKI Takahiro | 2005-05-30 01:59:59 | Re: O_DIRECT for WAL writes |