Re: Improving replay of XLOG_BTREE_VACUUM records - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Improving replay of XLOG_BTREE_VACUUM records
Date
Msg-id CAM-w4HPUWa4qXwsFV_zJ3+Hsik1vV7g7GxYrnbqyZpGaWBCMaw@mail.gmail.com
Whole thread Raw
In response to Re: Improving replay of XLOG_BTREE_VACUUM records  (Andres Freund <andres@anarazel.de>)
Responses Re: Improving replay of XLOG_BTREE_VACUUM records
List pgsql-hackers
On Sun, Jul 26, 2015 at 1:46 PM, Andres Freund <andres@anarazel.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



pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: exposing pg_controldata and pg_config as functions
Next
From: Alvaro Herrera
Date:
Subject: Re: exposing pg_controldata and pg_config as functions