SSL SYSCALL error: A blocking operation was interrupted by a call to WSACancelBlockingCall

"vyang" <vyang@apt-cafm.com> writes:

I'm having trouble with postgres filling the log with SSL SYSCALL error: A
blocking operation was interrupted by a call to WSACancelBlockingCall.

That was fixed some time ago:

2007-05-17 21:20 tgl

* src/backend/libpq/: be-secure.c (REL7_4_STABLE), be-secure.c
(REL8_1_STABLE), be-secure.c (REL8_0_STABLE), be-secure.c
(REL8_2_STABLE), be-secure.c: Remove redundant logging of send
failures when SSL is in use. While pqcomm.c had been taught not to
do that ages ago, the SSL code was helpfully bleating anyway.
Resolves some recent reports such as bug #3266; however the
underlying cause of the related bug #2829 is still unclear.

Update to a newer release.

regards, tom lane

Tom Lane wrote:

"vyang" <vyang@apt-cafm.com> writes:

I'm having trouble with postgres filling the log with SSL SYSCALL error: A
blocking operation was interrupted by a call to WSACancelBlockingCall.

That was fixed some time ago:

2007-05-17 21:20 tgl

* src/backend/libpq/: be-secure.c (REL7_4_STABLE), be-secure.c
(REL8_1_STABLE), be-secure.c (REL8_0_STABLE), be-secure.c
(REL8_2_STABLE), be-secure.c: Remove redundant logging of send
failures when SSL is in use. While pqcomm.c had been taught not to
do that ages ago, the SSL code was helpfully bleating anyway.
Resolves some recent reports such as bug #3266; however the
underlying cause of the related bug #2829 is still unclear.

Update to a newer release.

Actually, this only fixes the repeated logging that could take down your
entire server. The underlying issue is still there AFAIK, and can kill a
single connection.

Changing the SSL code to get around that is on my TODO for 8.4.

//Magnus