Skip site navigation (1) Skip section navigation (2)

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

From: Marko Kreen <markokr(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(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:09:07
Message-ID: e51f66da0903300709w5b591a55n2d18e085f1ddeb81@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On 3/30/09, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> 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.

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

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2009-03-30 14:13:24
Subject: Re: psql \d* and system objects
Previous:From: Tom LaneDate: 2009-03-30 14:06:24
Subject: Re: PQinitSSL broken in some use casesf

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group