Re: Idle processes chewing up CPU?
От | Brendan Hill |
---|---|
Тема | Re: Idle processes chewing up CPU? |
Дата | |
Msg-id | 00b001ca3cc9$ca371120$5ea53360$@net обсуждение исходный текст |
Ответ на | Re: Idle processes chewing up CPU? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Idle processes chewing up CPU?
|
Список | pgsql-general |
Hi Tom, Makes sense to me. Seems to be happening rarely now. I'm not all that familiar with the open source process, is this likely to be included in the next release version? -Brendan -----Original Message----- From: Tom Lane [mailto:tgl@sss.pgh.pa.us] Sent: Monday, 21 September 2009 5:25 AM To: Brendan Hill Cc: 'Craig Ringer'; pgsql-general@postgresql.org Subject: Re: [GENERAL] Idle processes chewing up CPU? "Brendan Hill" <brendanh@jims.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
В списке pgsql-general по дате отправления: