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

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Marko Kreen <markokr(at)gmail(dot)com>
Cc: Postgres Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 8.3.5: Crash in CountActiveBackends() - lockless race?
Date: 2009-03-30 14:02:02
Message-ID: 49D0D0DA.2000501@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Marko Kreen wrote:
> On 3/30/09, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2009-03-30 14:05:58 Re: psql \d* and system objects
Previous Message Marko Kreen 2009-03-30 13:47:55 Re: 8.3.5: Crash in CountActiveBackends() - lockless race?