On 3/30/09, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > Marko Kreen wrote: > > > On 3/30/09, Heikki Linnakangas > <heikki.linnakan...@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.
Yes, but that way it's well-defined what pointer you can get there - it can only be a pointer that is just being removed. And you know that if the ProcArrayRemove does not invalidate any fields before LWunlock, the struct data is valid. > I agree it's a bit dirty, but seems safe as the PGPROC entries are in > shared memory. I understand that the pointer is valid, but what about data it is pointing to? > (clearing the pointer might be a good idea anyway, though, for debugging > purposes) Yes, I think it would be good idea. > > 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. Ok. -- marko -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers