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

From: Marko Kreen <markokr(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Postgres Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 8.3.5: Crash in CountActiveBackends() - lockless race?
Date: 2009-03-30 14:36:41
Message-ID: e51f66da0903300736g4062100cu6675edcdd4c9f992@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 3/30/09, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2009-03-30 14:43:01 Re: psql \d* and system objects
Previous Message Tom Lane 2009-03-30 14:29:25 Re: PQinitSSL broken in some use casesf