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

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: 8.3.5: Crash in CountActiveBackends() - lockless race?
Дата
Msg-id 49D0D0DA.2000501@enterprisedb.com
обсуждение исходный текст
Ответ на Re: 8.3.5: Crash in CountActiveBackends() - lockless race?  (Marko Kreen <markokr@gmail.com>)
Ответы Re: 8.3.5: Crash in CountActiveBackends() - lockless race?
Re: 8.3.5: Crash in CountActiveBackends() - lockless race?
Список pgsql-hackers
Marko Kreen wrote:
> On 3/30/09, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote:
>>  Agreed. And more importantly, it puts the onus of getting it right into
>> CountActiveBackends, which is the one who's breaking the rules. We don't
>> necessarily need to clear the pointer in ProcArrayRemove either, the count
>> doesn't need to be accurate.
> 
> 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.

I agree it's a bit dirty, but seems safe as the PGPROC entries are in 
shared memory.

(clearing the pointer might be a good idea anyway, though, for debugging 
purposes)

> Also, are there other functions that try lockless access on proc_array?

We do set fields in MyProc without holding the lock, but that should be 
fine.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: PQinitSSL broken in some use casesf
Следующее
От: Marko Kreen
Дата:
Сообщение: Re: 8.3.5: Crash in CountActiveBackends() - lockless race?