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

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: "could not reattach to shared memory" on buildfarm member dory
Дата
Msg-id 20180428135923.GO27724@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: "could not reattach to shared memory" on buildfarm member dory  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Greetings,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Noah Misch <noah@leadboat.com> writes:
> > On Tue, Apr 24, 2018 at 11:37:33AM +1200, Thomas Munro wrote:
> >> Maybe try asking what's mapped there with VirtualQueryEx() on failure?
>
> > +1.  An implementation of that:
> > https://www.postgresql.org/message-id/20170403065106.GA2624300%40tornado.leadboat.com
>
> Not seeing any other work happening here, I pushed a little bit of
> quick-hack investigation code.  This is based on noting that
> VirtualAllocEx is documented as rounding the allocation up to a page
> boundary (4K), but there's nothing specific about whether or how much
> CreateFileMapping or MapViewOfFileEx might round up.  The observed
> failures could be explained if those guys might eat more virtual
> address space for the same request size as VirtualAllocEx does.
> This is a stretch, for sure, but given the lack of any other theories
> we might as well check it.

Sounds good to me.  Just as an FYI, there are a couple folks taking a
look at the system and trying to figure out what's going on.  We've seen
an Event ID 1530 error in the Windows Event log associated with
vctip.exe which Visual Studio was running with the build, but only
sometimes.  When vctip.exe is being run and then finishes, it goes and
cleans things up which seems to be what's triggering the 1530 and that
appears to correllate with the failures, but hard to say if that's
really a smoking gun or is just coincidence.

Thanks!

Stephen

Вложения

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

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: Toast issues with OldestXmin going backwards
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: [HACKERS] Clock with Adaptive Replacement