On Tue, May 10, 2011 at 9:45 AM, Merlin Moncure <mmonc...@gmail.com> wrote: > I see: here's a comment that was throwing me off: > + /* > + * If we didn't get the lock and it turns out we need it, we'll have > to > + * unlock and re-lock, to avoid holding the buffer lock across an I/O. > + * That's a bit unfortunate, but hopefully shouldn't happen often. > + */ > > I think that might be phrased as "didn't get the pin and it turns out > we need it because the bit can change after inspection". The visible > bit isn't 'wrong' as suggested in the comments, it just can change so > that it becomes wrong. Maybe a note of why it could change would be > helpful.
Oh, I see. I did write "lock" when I meant "pin", and your other point is well-taken as well. Here's a revised version with some additional wordsmithing. > Other than that, it looks pretty good...ISTM an awfully small amount > of code to provide what it's doing (that's a good thing!). Thanks. It's definitely not big in terms of code footprint; it's mostly a matter of making sure we've dotted all the "i"s and crossed all the "t"s. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
visibility-map-v3.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
