Re: Still something fishy in the fastpath lock stuff

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Still something fishy in the fastpath lock stuff
Date: 2014-03-31 19:04:55
Message-ID: 21832.1396292695@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Mar 26, 2014 at 12:59 AM, Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2014-03-31 19:06:51 Re: B-Tree support function number 3 (strxfrm() optimization)
Previous Message Robert Haas 2014-03-31 19:04:03 Re: PATCH: decreasing memory needlessly consumed by array_agg