Re: crash-safe visibility map, take five

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: crash-safe visibility map, take five
Дата
Msg-id BANLkTi=hK9SXuJt5L5xfJfxYLcwmhXFb_A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: crash-safe visibility map, take five  (Merlin Moncure <mmoncure@gmail.com>)
Ответы Re: crash-safe visibility map, take five
Список pgsql-hackers
On Tue, May 10, 2011 at 9:45 AM, Merlin Moncure <mmoncure@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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Merlin Moncure
Дата:
Сообщение: Re: the big picture for index-only scans
Следующее
От: Mark
Дата:
Сообщение: ts_rank