missing locking in at least INSERT INTO view WITH CHECK
От | Andres Freund |
---|---|
Тема | missing locking in at least INSERT INTO view WITH CHECK |
Дата | |
Msg-id | 20131023011855.GC823737@alap2.anarazel.de обсуждение исходный текст |
Ответы |
Re: missing locking in at least INSERT INTO view WITH CHECK
Re: missing locking in at least INSERT INTO view WITH CHECK Re: missing locking in at least INSERT INTO view WITH CHECK |
Список | pgsql-hackers |
Hi, Using the same debugging hack^Wpatch (0001) as in the matview patch (0002) an hour or so ago I noticed that INSERT INTO view WITH CHECK doesn't lock the underlying relations properly. I've attached a sort-of-working (0003) hack but I really doubt it's the correct approach, I don't really know enough about that area of the code. This looks like something that needs to be fixed. 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. 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. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: