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 по дате отправления: