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  (Andres Freund <andres@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Kevin Grittner
Дата:
Сообщение: Re: [GENERAL] Cannot create matview when referencing another not-populated-yet matview in subquery
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Creating Empty Index