Re: [PATCH] introduce XLogLockBlockRangeForCleanup() - Mailing list pgsql-hackers

From Amit Khandekar
Subject Re: [PATCH] introduce XLogLockBlockRangeForCleanup()
Date
Msg-id CACoZds3Q4dufqdFGJvMqihbprPx2rR_4xL3=YtMZiZ6Joc2uXg@mail.gmail.com
Whole thread Raw
In response to [PATCH] introduce XLogLockBlockRangeForCleanup()  (Abhijit Menon-Sen <ams@2ndQuadrant.com>)
Responses Re: [PATCH] introduce XLogLockBlockRangeForCleanup()  (Abhijit Menon-Sen <ams@2ndQuadrant.com>)
Re: [PATCH] introduce XLogLockBlockRangeForCleanup()  (Simon Riggs <simon@2ndQuadrant.com>)
List 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 by date:

Previous
From: Amit Kapila
Date:
Subject: Re: better atomics - v0.5
Next
From: Michael Paquier
Date:
Subject: Re: WAL replay bugs