"Brendan Hill" <brendanh@xxxxxxxx> writes: > 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? Can you confirm that that change actually fixes the problem you're seeing? I'm happy to apply it if it does, but I'd like to know that the problem is dealt with. regards, tom lane > -----Original Message----- > From: Tom Lane [mailto:tgl@xxxxxxxxxxxxx] > Sent: Monday, 21 September 2009 5:25 AM > To: Brendan Hill > Cc: 'Craig Ringer'; pgsql-general@xxxxxxxxxxxxxx > Subject: Re: Idle processes chewing up CPU? > "Brendan Hill" <brendanh@xxxxxxxx> 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 > -- > Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
