Search Postgresql Archives

Re: Connection issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi again,


> On 6. Feb 2019, at 17:19, Adrian Klaver <adrian.klaver@xxxxxxxxxxx> wrote:
> 
> On 2/6/19 7:18 AM, Maximilian Tyrtania wrote:
>> Well, the problem being a Parallels issue is just a wild theory of mine, it could well be something else. Honstly I don't recall updating anything in that area. As Mr. Gomez suggested I tried to
> 
> So from a previous post:
> 
> > Have you recently updated any of the involved software?
> 
> Well, sure, but after I saw I couldn't connect ...
> 
> So what happened in the interval between the time you could connect and the time you could not?

I did update parts of my app (including the plugin which in turn encapsulates libpq). I did not update my parallels installation, as far as I remember. Sorry if I was unclear about that.

>> ping - worked
>> telnet - did not work (infact I couldn't telnet anywhere)
> 
> In my experience telnet is generally disabled these days.

I had to enable it on my Windows box, if that's what you mean. The "telnet" command works by itself, but I didnt receive anything when trying to telnet to some other machine.

>> tracert - worked
>> from my windows 10 box (didn't bother to check on my Mac as I have noc issues there). Still curious as to why the server would say "Connection reset by peer".
> 
> Well if you are running Windows --> Parallels --> OS X(Mac) --> Serve, you are effectively testing the Mac also.
> 
> As to 'Connection reset by peer':
> 
> A grep of the Postgres source find this:
> 
> interfaces/libpq/win32.c
> 
> * Contains table and functions for looking up win32 socket error
> * descriptions. But will/may contain other win32 helper functions
> * for libpq.
> 
> 
> WSAECONNRESET, "Connection reset by peer"
> 
> Looking up WSAECONNRESET finds this:
> 
> https://docs.microsoft.com/en-us/windows/desktop/WinSock/windows-sockets-error-codes-2
> 
> 
> WSAECONNRESET
> 10054
> 
> Connection reset by peer.
>    An existing connection was forcibly closed by the remote host. This normally results if the peer application on the remote host is suddenly stopped, the host is rebooted, the host or remote network interface is disabled, or the remote host uses a hard close (see setsockopt for more information on the SO_LINGER option on the remote socket). This error may also result if a connection was broken due to keep-alive activity detecting a failure while one or more operations are in progress. Operations that were in progress fail with WSAENETRESET. Subsequent operations fail with WSAECONNRESET.

Ah, thanks for digging that up. Hmm, sounds as if something is definetly wrong on my windows box.

I'll try contacting the Parallels support guys.

Thanks again,

Max 




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux