Re: missing locking in at least INSERT INTO view WITH CHECK
От | Kevin Grittner |
---|---|
Тема | Re: missing locking in at least INSERT INTO view WITH CHECK |
Дата | |
Msg-id | 1383437124.9165.YahooMailNeo@web162902.mail.bf1.yahoo.com обсуждение исходный текст |
Ответ на | missing locking in at least INSERT INTO view WITH CHECK (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: missing locking in at least INSERT INTO view WITH CHECK
|
Список | pgsql-hackers |
Andres Freund <andres@2ndquadrant.com> wrote: > the matview patch (0002) This is definitely needed as a bug fix. Will adjust comments and commit, back-patched to 9.3. Thanks for spotting this, and thanks for the fix! > Also attached is 0004 which just adds a heap_lock() around a > newly created temporary table in the matview code which shouldn't > be required for correctness but gives warm and fuzzy feelings as > well as less debugging noise. Will think about this. I agree is is probably worth doing something to reduce the noise when looking for cases that actually matter. > Wouldn't it be a good idea to tack such WARNINGs (in a proper and > clean form) to index_open (checking the underlying relation is > locked), relation_open(..., NoLock) (checking the relation has > previously been locked) and maybe RelationIdGetRelation() when > cassert is enabled? ISTM we frequently had bugs around this. It would be nice to have such omissions pointed out during early testing. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: