Re: Unknown winsock error 10061 - Mailing list pgsql-bugs

From Dave Page
Subject Re: Unknown winsock error 10061
Date
Msg-id 937d27e10907070646t35572692v1f86ba4367712011@mail.gmail.com
Whole thread Raw
In response to Re: Unknown winsock error 10061  (Wojciech Strzałka <wstrzalka@gmail.com>)
Responses Re: Unknown winsock error 10061  (Wojciech Strzałka <wstrzalka@gmail.com>)
List pgsql-bugs
2009/7/7 Wojciech Strza=C5=82ka <wstrzalka@gmail.com>:
>
> =C2=A0 Sorry if what i'm talking is completely silly, but
> =C2=A0 the error code (ERROR_INVALID_ADDRESS - 487 (0x1E7)) returned from
> =C2=A0 MapViewOfFileEx suggest the ShMem address is wrong. The Windows
> =C2=A0 error codes are usually not really helpfull but
> =C2=A0 can we log the UsedShmemSegAddr and UsedShmemSegID in
> =C2=A0 PGSharedMemoryCreate and maybe also on successful PGSharedMemoryRe=
Attach
> =C2=A0 in DEBUG log level?

We could, but I don't see how it could be wrong, as it's only set in
PGSharedMemoryCreate and when we pass it down from postmaster to
backend. If something we're being stomped on there, I'd expect it to
be a more random problem.

<reads code some more>

Although, the reattach does get called almost immediately following
the backend variables being read, so maybe they are getting clobbered,
and it's pretty much always shows up in the re-mapping of the shared
memory.

What distribution are you running? I'll see if I can hack up a build
with the extra debugging, but I need to get the integer_datetimes
option right for your database.

--=20
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com

pgsql-bugs by date:

Previous
From: Wojciech Strzałka
Date:
Subject: Re: Unknown winsock error 10061
Next
From: Wojciech Strzałka
Date:
Subject: Re: Unknown winsock error 10061