Re: [PATCH] introduce XLogLockBlockRangeForCleanup()

Поиск
Список
Период
Сортировка
От Amit Khandekar
Тема Re: [PATCH] introduce XLogLockBlockRangeForCleanup()
Дата
Msg-id CACoZds3Q4dufqdFGJvMqihbprPx2rR_4xL3=YtMZiZ6Joc2uXg@mail.gmail.com
обсуждение исходный текст
Ответ на [PATCH] introduce XLogLockBlockRangeForCleanup()  (Abhijit Menon-Sen <ams@2ndQuadrant.com>)
Ответы Re: [PATCH] introduce XLogLockBlockRangeForCleanup()  (Abhijit Menon-Sen <ams@2ndQuadrant.com>)
Re: [PATCH] introduce XLogLockBlockRangeForCleanup()  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers



On 13 June 2014 14:10, Abhijit Menon-Sen <ams@2ndquadrant.com> wrote:
nbtxlog.c:btree_xlog_vacuum() contains the following comment:

     * XXX we don't actually need to read the block, we just need to
     * confirm it is unpinned. If we had a special call into the
     * buffer manager we could optimise this so that if the block is
     * not in shared_buffers we confirm it as unpinned.

The attached patch introduces an XLogLockBlockRangeForCleanup() function
that addresses this, as well as a "special call into the buffer manager"
that makes it possible to lock the buffers without reading them.

In GetBufferWithoutRelcache(), I was wondering, rather than calling PinBuffer(), if we do this :
LockBufHdr(buf);
PinBuffer_Locked(buf);
valid = ((buf->flags & BM_VALID) != 0);
then we can avoid having the new buffer access strategy BAS_DISCARD that is introduced in this patch. And so the code changes in freelist.c would not be necessary.

Will give further thought on the overall logic in XLogLockBlockRangeForCleanup().
 
will follow up with some performance numbers soon.

Yes, that would be nice. 

-Amit

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: better atomics - v0.5
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: WAL replay bugs