Re: crash-safe visibility map, take five

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: crash-safe visibility map, take five
Date: 2011-05-10 14:08:56
Message-ID: BANLkTi=hK9SXuJt5L5xfJfxYLcwmhXFb_A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, May 10, 2011 at 9:45 AM, Merlin Moncure <mmoncure(at)gmail(dot)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

Attachment Content-Type Size
visibility-map-v3.patch application/octet-stream 29.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-05-10 14:47:43 collateral benefits of a crash-safe visibility map
Previous Message Merlin Moncure 2011-05-10 13:59:59 Re: the big picture for index-only scans