Re: Improving replay of XLOG_BTREE_VACUUM records

On Sun, Jul 26, 2015 at 1:46 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> To me it sounds like this shouldn't go through the full ReadBuffer()
> rigamarole. That code is already complex enough, and here it's really
> not needed. I think it'll be much easier to review - and actually faster
> in many cases to simply have something like
>
> bool
> BufferInCache(Relation, ForkNumber, BlockNumber)
> {
> /* XXX: setup tag, hash, partition */
>
> LWLockAcquire(newPartitionLock, LW_SHARED);
> buf_id = BufTableLookup(&newTag, newHash);
> LWLockRelease(newPartitionLock);
> return buf_id != -1;
> }
>
> and then fall back to the normal ReadBuffer() when it's in cache.

I guess I'm missing something but how is this API useful? As soon as
its returned it the result might be invalid since before you actually
make use of the return value another process could come and read in
and pin the page in question. Is this part of some interlock where you
only have to know it was unpinned at some point in time since some
other event?

--
greg