Re: Still something fishy in the fastpath lock stuff - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Still something fishy in the fastpath lock stuff
Date
Msg-id 21832.1396292695@sss.pgh.pa.us
Whole thread Raw
In response to Re: Still something fishy in the fastpath lock stuff  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Mar 26, 2014 at 12:59 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> It seems to me that the simplest thing to do might be
>> just this:
>> 
>> -static FastPathStrongRelationLockData *FastPathStrongRelationLocks;
>> +static volatile FastPathStrongRelationLockData *FastPathStrongRelationLocks;
>> 
>> Do you see any problem with that approach?

> Hearing nothing, I went ahead and did this.

Sorry, I've been preoccupied with personal matters for the past little
while, and hadn't had time to think about this.  After a review of the
code it looks probably all right to me.

> I see that the failure on
> prairiedog only occurred once, so I don't know how we'll know whether
> this fixed the problem that caused that failure or merely fixed a
> problem that could cause a failure, but I'm not sure what else we can
> really do at this point.

Well, it's only one failure, but it occurred after prairiedog had run
a grand total of 20 buildfarm cycles on 9.2 and newer, so I'm thinking
that the probability of failure on that machine is more than epsilon.
If we don't see it again for a good long while then I'll believe that
this fixed it.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: PATCH: decreasing memory needlessly consumed by array_agg
Next
From: Peter Geoghegan
Date:
Subject: Re: B-Tree support function number 3 (strxfrm() optimization)