Re: Heap truncation without AccessExclusiveLock (9.4) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Heap truncation without AccessExclusiveLock (9.4)
Date
Msg-id 17573.1368724542@sss.pgh.pa.us
Whole thread Raw
In response to Re: Heap truncation without AccessExclusiveLock (9.4)  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Heap truncation without AccessExclusiveLock (9.4)  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
>> 2. If you don't find an entry for your target rel in the cache, aren't
>> you still going to have to do an lseek?

> Don't think of it as a cache.  The caching happens inside each
> backend's relcache; the shared memory structure is just a tool to
> force those caches to be revalidated when necessary.

Hmm.  Now I see: it's not a cache, it's a Bloom filter.  The failure
mode I was thinking of is inapplicable, but there's a different one:
you have to be absolutely positive that *any* operation that extends the
file will update the relevant filter entry.  Still, I guess that we're
already assuming that any such op will take the relation's extension
lock, so it should be easy enough to find all the places to fix.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Heap truncation without AccessExclusiveLock (9.4)
Next
From: "David E. Wheeler"
Date:
Subject: Re: Patch proposal: query result history in psql