Re: "could not reattach to shared memory" on buildfarm member dory

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: "could not reattach to shared memory" on buildfarm member dory
Дата
Msg-id CAEepm=0kRF7Hrd2R72FJLdQneV1HATjJM_ArbjZw=-ZF3RT7+Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: "could not reattach to shared memory" on buildfarm member dory  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: "could not reattach to shared memory" on buildfarm member dory  (Noah Misch <noah@leadboat.com>)
Список pgsql-hackers
On Tue, Apr 24, 2018 at 11:18 AM, Stephen Frost <sfrost@snowman.net> wrote:
> Greetings,
>
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> So far, dory has failed three times with essentially identical symptoms:
>>
>> 2018-04-23 19:57:10.624 GMT [2240] FATAL:  could not reattach to shared memory (key=0000000000000190,
addr=00000000018E0000):error code 487
 
>> 2018-04-23 15:57:10.657 EDT [8836] ERROR:  lost connection to parallel worker
>> 2018-04-23 15:57:10.657 EDT [8836] STATEMENT:  select count(*) from tenk1 group by twenty;
>> 2018-04-23 15:57:10.660 EDT [3820] LOG:  background worker "parallel worker" (PID 2240) exited with exit code 1
>>
>> Now how can this be?  We've successfully reserved and released the address
>> range we want to use, so it *should* be free at the instant we try to map.
>
> Yeah, that's definitely interesting.

I wondered if another thread with the right timing could map something
between the VirtualFree() and MapViewOfFileEx() calls, but  we don't
create the Windows signal handling thread until a bit later.  Could
there be any any other threads active in the process?

Maybe try asking what's mapped there with VirtualQueryEx() on failure?

-- 
Thomas Munro
http://www.enterprisedb.com


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: "could not reattach to shared memory" on buildfarm member dory
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Make description of heap records more talkative for flags