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
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? |