Re: missing locking in at least INSERT INTO view WITH CHECK
От | Andres Freund |
---|---|
Тема | Re: missing locking in at least INSERT INTO view WITH CHECK |
Дата | |
Msg-id | 20131105195909.GE14819@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: missing locking in at least INSERT INTO view WITH CHECK (Kevin Grittner <kgrittn@ymail.com>) |
Ответы |
Re: missing locking in at least INSERT INTO view WITH CHECK
|
Список | pgsql-hackers |
On 2013-11-05 11:56:25 -0800, Kevin Grittner wrote: > Andres Freund <andres@2ndquadrant.com> wrote: > > On 2013-11-02 17:05:24 -0700, Kevin Grittner wrote: > >> Andres Freund <andres@2ndquadrant.com> wrote: > > >>> 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. > > > > It's pretty much free, so I don't think there really is any > > reason to deviate from other parts of the code. Note how e.g. > > copy_heap_data(), DefineRelation() and ATRewriteTable() all lock > > the new relation, even if it just has been created and is (and in > > the latter two cases will always be) invisible. > > None of those locations are using heap_open() as the first > parameter to heap_close(). Oh! Sure, what I'd posted was just an absolutely crude hack that surely isn't committable. > I'm thinking of something like the attached instead. Looks fine to me, maybe add a short comment? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: