RE: [Patch] PQconnectPoll() is blocked if target_session_attrs isread-write
От | Tsunakawa, Takayuki |
---|---|
Тема | RE: [Patch] PQconnectPoll() is blocked if target_session_attrs isread-write |
Дата | |
Msg-id | 0A3221C70F24FB45833433255569204D1FC86575@G01JPEXMBYT05 обсуждение исходный текст |
Ответ на | [Patch] PQconnectPoll() is blocked if target_session_attrs isread-write ("Matsumura, Ryo" <matsumura.ryo@jp.fujitsu.com>) |
Ответы |
RE: [Patch] PQconnectPoll() is blocked if target_session_attrs isread-write
|
Список | pgsql-hackers |
From: Matsumura, Ryo [mailto:matsumura.ryo@jp.fujitsu.com] > Detail: > If target_session_attrs is set to read-write, PQconnectPoll() calls > PQsendQuery("SHOW transaction_read_only") althogh previous return value > was PGRES_POLLING_READING not WRITING. The current code probably assumes that PQsendQuery() to send "SHOW transaction_read_only" shouldn't block, because the messageis small enough to fit in the socket send buffer. Likewise, the code in CONNECTION_AWAITING_RESPONSE case sends authenticationdata using pg_fe_sendauth() without checking for the write-ready status. OTOH, the code in CONNECTION_MADEcase waits for write-ready status in advance before sending the startup packet. That's because the startuppacket could get large enough to cause pqPacketSend() to block. So, I don't think the fix is necessary. > In result, PQsendQuery() may be blocked in pqsecure_raw_write(). FWIW, if PQsendQuery() blocked during connection establishment, I think it should block in poll() called from .... from pqWait(),because the libpq's socket is set non-blocking. Regards Takayuki Tsunakawa
В списке pgsql-hackers по дате отправления: