Re: Improving replay of XLOG_BTREE_VACUUM records

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Improving replay of XLOG_BTREE_VACUUM records
Дата
Msg-id CAM-w4HPUWa4qXwsFV_zJ3+Hsik1vV7g7GxYrnbqyZpGaWBCMaw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Improving replay of XLOG_BTREE_VACUUM records  (Andres Freund <andres@anarazel.de>)
Ответы Re: Improving replay of XLOG_BTREE_VACUUM records  (Andres Freund <andres@anarazel.de>)
Список 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 по дате отправления:

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: exposing pg_controldata and pg_config as functions
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: exposing pg_controldata and pg_config as functions