From: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: missing locking in at least INSERT INTO view WITH CHECK |
Date: | 2013-11-03 00:05:24 |
Message-ID: | 1383437124.9165.YahooMailNeo@web162902.mail.bf1.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-11-03 03:01:07 | Re: Creating Empty Index |
Previous Message | Kevin Grittner | 2013-11-02 23:45:02 | Re: [GENERAL] Cannot create matview when referencing another not-populated-yet matview in subquery |