RE: [Patch] PQconnectPoll() is blocked if target_session_attrs is read-write

From: "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>
To: "Matsumura, Ryo" <matsumura(dot)ryo(at)jp(dot)fujitsu(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: [Patch] PQconnectPoll() is blocked if target_session_attrs is read-write
Date: 2019-07-25 04:12:55
Message-ID: 0A3221C70F24FB45833433255569204D1FC86575@G01JPEXMBYT05
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

From: Matsumura, Ryo [mailto:matsumura(dot)ryo(at)jp(dot)fujitsu(dot)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 message is small enough to fit in the socket send buffer. Likewise, the code in CONNECTION_AWAITING_RESPONSE case sends authentication data using pg_fe_sendauth() without checking for the write-ready status. OTOH, the code in CONNECTION_MADE case waits for write-ready status in advance before sending the startup packet. That's because the startup packet 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2019-07-25 05:38:40 Initdb failure
Previous Message vignesh C 2019-07-25 04:00:50 Re: POC: Cleaning up orphaned files using undo logs