On Tue, Aug 16, 2011 at 3:45 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> It would be nice to move the short-circuit test I recently inserted at >> the top of SIGetDataEntries() somewhere higher up in the call stack, >> but right now the layers of abstraction are so thick that it's not >> exactly clear how to do that. > > Glad you didn't try, because it would be wrong. The fact that there > are no outstanding messages in sinvaladt.c doesn't prove there are none > yet unprocessed inside ReceiveSharedInvalidMessages.
Oh. Good point. > Anyway, to get back to the original point: I'm getting less excited > about redoing the CLOBBER_CACHE_ALWAYS code at a different level. > The only thing that can really promise is that we find places outside > the cache code that are mistakenly holding onto cache entry pointers. > It can't do very much for the sort of problems I've been finding over > the past week, first because you need some other process actively > changing the underlying information (else the use of a stale cache entry > isn't a problem), and second because when you're looking for bugs > involving use of stale cache entries, over-enthusiastic flushing of the > cache can actually mask the bugs. > > I'd still like to think of a better test methodology, but I don't think > "force clobbers inside ReceiveSharedInvalidMessages" is it. Makes sense. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
