On Tue, Aug 16, 2011 at 3:45 PM, Tom Lane <tgl@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
