On Wed, Feb 3, 2010 at 08:23, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > Fujii Masao wrote: >> On Thu, Jan 14, 2010 at 7:04 PM, Heikki Linnakangas >> <heikki.linnakan...@enterprisedb.com> wrote: >>> 1. Walsender calls pq_wait() which calls select(), waiting for timeout, >>> or data to become available for reading in the underlying socket. >>> >>> 2. Client issues an SSL renegotiation by sending a message to the server >>> >>> 3. Server receives the message, and select() returns indicating that >>> data has arrived >>> >>> 4. Walsender calls HandleEndOfRep() which calls pq_getbyte(). >>> pq_readbyte() calls SSL_read(), which receives the renegotiation message >>> and handles it. No application data has arrived, however, so SSL_read() >>> blocks for some to arrive. It never does. >> >> What is the trigger of the renegotiation? The backend initiates it >> when the amount of data sent exceeds the RENEGOTIATION_LIMIT (which >> is defined in src/backend/libpq/be-secure.c). OTOH, I cannot find >> the code that the libpq explicitly does that. So I wonder if client >> (i.e., walreceiver in this case) really sends the SSL renegotiation >> message. Correct me if I'm wrong. > > I have no idea. I thought the SSL library can do so whenever it feels > like it, but I'm not sure.
It can only do it when we call the library. Which means at send or receive :-) But AFAIK either end (sender or receiver) can initiate it. > The other problem scenario was that the server receive only the first > half of an SSL packet. That doesn't produce any data available to read > with SSL_read(), so SSL_read() will block, but it does wake up a select(). Yeah. It can be re-woken, because SSL_read() will eventually be calling back into our own functions, but that would require a second signal before it wakes up of course.. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
