possible dsm bug in dsm_attach()

Поиск
Список
Период
Сортировка
Искать
От
Andres Freund
Тема
possible dsm bug in dsm_attach()
Дата
в 12:43:40
Msg-id
20140506124334.GQ17909@awork2.anarazel.de
Список
Дерево обсуждения
possible dsm bug in dsm_attach() Andres Freund <andres@2ndquadrant.com>
Re: possible dsm bug in dsm_attach() Robert Haas <robertmhaas@gmail.com>
Re: possible dsm bug in dsm_attach() Andres Freund <andres@2ndquadrant.com>
Re: possible dsm bug in dsm_attach() Robert Haas <robertmhaas@gmail.com>
Re: possible dsm bug in dsm_attach() Andres Freund <andres@2ndquadrant.com>
Re: possible dsm bug in dsm_attach() Robert Haas <robertmhaas@gmail.com>
Re: possible dsm bug in dsm_attach() Amit Kapila <amit.kapila16@gmail.com>
Re: possible dsm bug in dsm_attach() Robert Haas <robertmhaas@gmail.com>
Hi,

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?

Greetings,

Andres Freund

-- Andres Freund	                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services


В списке pgsql-hackers по дате отправления
От: Simon Riggs
Дата:
Сообщение: Re: pg_shmem_allocations view
От: Neil Tiffin
Дата:
FAQ