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

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