On 7/24/15 1:53 AM, Heikki Linnakangas wrote:
On 05/02/2015 02:10 AM, Jim Nasby wrote:
This looks like a good way to address this until the more significant
work can be done.
I'm not a fan of "RBM_ZERO_NO_BM_VALID"; how about RBM_ZERO_BM_INVALID?
or BM_NOT_VALID? Or maybe I'm just trying to impose too much English on
the code; I see the logic to NO_BM_VALID...
+ * RBM_ZERO_NO_BM_VALID is the same as RBM_ZERO_AND_LOCK, but does
not set
+ * BM_VALID bit before returning buffer so that noone could pin it.
It would be better to explain why we want that mode. How about:
RBM_ZERO_NO_BM_VALID is the same as RBM_ZERO_AND_LOCK but does not set
BM_VALID before returning the buffer. This is done to ensure that no one
can pin the buffer without actually reading the buffer contents in. This
is necessary while replying XLOG_BTREE_VACUUM records in hot standby.
That's a rather strange mode. The BM_VALID flag is internal to the
buffer manager - if you don't know how the buffer manager works, you
cannot understand that description. I couldn't quite understand what
that means myself. What can or can you not do with a buffer that's not
marked as BM_VALID? I'd suggest a mode like this instead:
In RBM_IF_IN_CACHE mode, the page is returned if it is in the buffer
cache already. If it's not, it is not read from disk, and InvalidBuffer
is returned instead.
+1, though I think it's still worth mentioning why we're doing this (so
we know no one else can pin the buffer).
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
