Re: possible dsm bug in dsm_attach()

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: possible dsm bug in dsm_attach()
Дата
Msg-id CA+Tgmob97DBO8RUjRGiHVBvrMbZtr08SxvOs_atKiSqoyvbBog@mail.gmail.com
обсуждение исходный текст
Ответ на possible dsm bug in dsm_attach()  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: possible dsm bug in dsm_attach()
Список pgsql-hackers
On Tue, May 6, 2014 at 8:43 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> dsm_attach() does the following:
>
>         nitems = dsm_control->nitems;
>         for (i = 0; i < nitems; ++i)
>         {
>                 /* If the reference count is 0, the slot is actually unused. */
>                 if (dsm_control->item[i].refcnt == 0)
>                         continue;
>
>                 /*
>                  * If the reference count is 1, the slot is still in use, but the
>                  * segment is in the process of going away.  Treat that as if we
>                  * didn't find a match.
>                  */
>                 if (dsm_control->item[i].refcnt == 1)
>                         break;
>
>                 /* Otherwise, if the descriptor matches, we've found a match. */
>                 if (dsm_control->item[i].handle == seg->handle)
>                 {
>                         dsm_control->item[i].refcnt++;
>                         seg->control_slot = i;
>                         break;
>                 }
>         }
>
> The break because of refcnt == 1 doesn't generally seem to be a good
> idea. Why are we bailing if there's *any* segment that's in the process
> of being removed? I think the check should be there *after* the
> dsm_control->item[i].handle == seg->handle check?

You are correct.  Good catch.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Neil Tiffin
Дата:
Сообщение: Re: pgaudit - an auditing extension for PostgreSQL
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: pgindent run