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

On 3/30/09, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote:
> Marko Kreen wrote:
>
> > 1.  Add memory barrier to ProcArrayAdd/ProcArrayRemove between pointer
> >    and count update.  This guarantees that partial slots will not be seen.
> >
> > 2.  Always clear the pointer in ProcArrayRemove and check for NULL
> >    in all "lockless" access points.  This guarantees that partial slots
> >    will be either NULL or just-freed ones, before the barrier in
> >    LWLockRelease(), which means the contents should be still sensible.
> >
> > #1 seems to require platform-specific code, which we don't have yet?
> >
>
>  Marking the pointer as volatile should work.

No, "volatile" affects only compiler, we need to notify CPU.

> > So #2 may be easier solution.
>
>  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.  Lockless operations are unobvious enough...

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

-- 
marko