Re: Still something fishy in the fastpath lock stuff

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Still something fishy in the fastpath lock stuff
Дата
Msg-id 21832.1396292695@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Still something fishy in the fastpath lock stuff  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: PATCH: decreasing memory needlessly consumed by array_agg
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: B-Tree support function number 3 (strxfrm() optimization)