Re: 8.3.5: Crash in CountActiveBackends() - lockless race?

Поиск
Список
Период
Сортировка
От Marko Kreen
Тема Re: 8.3.5: Crash in CountActiveBackends() - lockless race?
Дата
Msg-id e51f66da0903300736g4062100cu6675edcdd4c9f992@mail.gmail.com
обсуждение исходный текст
Ответ на Re: 8.3.5: Crash in CountActiveBackends() - lockless race?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: 8.3.5: Crash in CountActiveBackends() - lockless race?
Список pgsql-hackers
On 3/30/09, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>
> > Marko Kreen wrote:
>  >> Without reset in ProcArrayRemove we may use some ancient pointer that
>  >> may point to garbage?  I don't think it's good coding style to allow
>  >> that to happen.
>
>  > Well, that can happen anyway. CountActiveBackends() could fetch the
>  > pointer and determine that it's not NULL, just before ProcArrayRemove
>  > clears it.
>
>
> Dead PGPROC entries are just put into a list for reuse, so the pointer
>  would still point at storage that looked like a PGPROC.  I concur with
>  Heikki's theory that the observed crash must have been from fetching a
>  pointer that was never yet not NULL.

Well, that was also my theory.  But my point is that such lockless code
should be written in more stricter way so it's effects can be clearly
deduced.  Or at least such roundabout effects should be commented -
"Ancient pointer here would still point to PGPROC struct".

-- 
marko


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: psql \d* and system objects
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: psql \d* and system objects