Re: Idle processes chewing up CPU?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Brendan Hill" <brendanh(at)jims(dot)net>
Cc: "'Craig Ringer'" <craig(at)postnewspapers(dot)com(dot)au>, pgsql-general(at)postgresql(dot)org
Subject: Re: Idle processes chewing up CPU?
Date: 2009-09-20 19:24:35
Message-ID: 25386.1253474675@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"Brendan Hill" <brendanh(at)jims(dot)net> writes:
> My best interpretation is that an SSL client dirty disconnected while
> running a request. This caused an infinite loop in pq_recvbuf(), calling
> secure_read(), triggering my_sock_read() over and over. Calling
> SSL_get_error() in secure_read() returns 10045 (either connection reset, or
> WSAEOPNOTSUPP, I'm not sure) - after this, pq_recvbuf() appears to think
> errno=EINTR has occurred, so it immediately tries again.

I wonder if this would be a good idea:

#ifdef USE_SSL
if (port->ssl)
{
int err;

rloop:
+ errno = 0;
n = SSL_read(port->ssl, ptr, len);
err = SSL_get_error(port->ssl, n);
switch (err)
{
case SSL_ERROR_NONE:
port->count += n;
break;

It looks to me like the basic issue is that pq_recvbuf is expecting
a relevant value of errno when secure_read returns -1, and there's
some path in the Windows case where errno doesn't get set, and if
it just happens to have been EINTR then we've got a loop.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Devrim GÜNDÜZ 2009-09-20 21:24:34 Re: MD5 sum mismatch in source rpm
Previous Message Brendan Hill 2009-09-20 10:37:08 Re: Idle processes chewing up CPU?