From: | Amit Khandekar <amit(dot)khandekar(at)enterprisedb(dot)com> |
---|---|
To: | Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] introduce XLogLockBlockRangeForCleanup() |
Date: | 2014-07-03 05:45:53 |
Message-ID: | CACoZds3Q4dufqdFGJvMqihbprPx2rR_4xL3=YtMZiZ6Joc2uXg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 13 June 2014 14:10, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2014-07-03 05:48:50 | Re: WAL replay bugs |
Previous Message | Amit Kapila | 2014-07-03 05:26:51 | Re: better atomics - v0.5 |