Обсуждение: Re: [HACKERS] Another crack at doing a Win32 build under MINGW

Поиск
Список
Период
Сортировка

Re: [HACKERS] Another crack at doing a Win32 build under MINGW

От
"Magnus Hagander"
Дата:
> Dann Corbit wrote:
> > I am able to build now, and perform initdb.  However, I
> cannot run the
> > postmaster.  I don't know how far along the port is.  What is the
> > current state of the port to Win32?
> >
> > dcorbit@DANNFAST /usr/local/pgsql/bin
> > $ postmaster -D u:/pgdata
> > LOG:  select() failed in postmaster: No such file or directory
> >
> > dcorbit@DANNFAST /usr/local/pgsql/bin
> > $ FATAL:  could not attach to proper memory at fixed address:
> > shmget(key=5432001, addr=00E10000) failed: No such file or directory
>
> [ email moved to win32 list.]
>
> They have only a few regression tests failing, so we are very
> far along.
>
> The message you are seeing looks like code that assumes that
> a child can map to the same shared memory address as the
> postmaster.  We haven't seen that fail for anyone before, but
> it is an assumption we weren't sure about.  Of course this is
> all a guess.


I've seen both these messages after each other when -i is not specified.
Been meaning to adress the issue of it not failing gracefully without -i
on win32.

Anyway. It seems the postmaster goes down while a child process is still
going up (stats collector, I guess) or something along that line. This
way the child can't attach to shared memory, and there you go.

If you add PID information to the log, you will notice that the messages
are from two different processes.

//Magnus

Re: [HACKERS] Another crack at doing a Win32 build under MINGW

От
"Andrew Dunstan"
Дата:
Magnus Hagander said:
>>
>> The message you are seeing looks like code that assumes that
>> a child can map to the same shared memory address as the
>> postmaster.  We haven't seen that fail for anyone before, but
>> it is an assumption we weren't sure about.  Of course this is
>> all a guess.
>
>
> I've seen both these messages after each other when -i is not
> specified. Been meaning to adress the issue of it not failing
> gracefully without -i on win32.
>
> Anyway. It seems the postmaster goes down while a child process is
> still going up (stats collector, I guess) or something along that line.
> This way the child can't attach to shared memory, and there you go.
>
> If you add PID information to the log, you will notice that the
> messages are from two different processes.
>

Is there a case for forcing -i and ignoring the GUC setting on Windows?
Since we can't do Unix domain sockets there it would seem to make sense.

cheers

andrew