Re: 8.3.5: Crash in CountActiveBackends() - lockless race? - Mailing list pgsql-hackers

From Marko Kreen
Subject Re: 8.3.5: Crash in CountActiveBackends() - lockless race?
Date
Msg-id e51f66da0903300736g4062100cu6675edcdd4c9f992@mail.gmail.com
Whole thread Raw
In response to Re: 8.3.5: Crash in CountActiveBackends() - lockless race?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: 8.3.5: Crash in CountActiveBackends() - lockless race?  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: psql \d* and system objects
Next
From: Bruce Momjian
Date:
Subject: Re: psql \d* and system objects