Re: locks in CREATE TRIGGER, ADD FK
От | Tom Lane |
---|---|
Тема | Re: locks in CREATE TRIGGER, ADD FK |
Дата | |
Msg-id | 4750.1117420419@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: locks in CREATE TRIGGER, ADD FK (Neil Conway <neilc@samurai.com>) |
Список | 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 по дате отправления: