missing locking in at least INSERT INTO view WITH CHECK - Mailing list pgsql-hackers

From Andres Freund
Subject missing locking in at least INSERT INTO view WITH CHECK
Date
Msg-id 20131023011855.GC823737@alap2.anarazel.de
Whole thread Raw
Responses Re: 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  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Re: missing locking in at least INSERT INTO view WITH CHECK  (Kevin Grittner <kgrittn@ymail.com>)
List 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 by date:

Previous
From: Noah Misch
Date:
Subject: Re: Why the asprintf patch is still breaking the buildfarm
Next
From: Andres Freund
Date:
Subject: Re: missing locking in at least INSERT INTO view WITH CHECK