[pgpool-general: 7968] Re: Hang with Skunk because Flush not honoured

[Tatsuo Ishii]

> Hi,
> 
> We are trying to use a Scala Skunk client with a Pgpool-II server. Skunk uses the extended protocol for prepared statements and checks every step for errors. To this end, it uses the following protocol sequence:
> 
> 1. Parse
> 2. Flush
> 3. Await response and check for errors
> 4. Describe statement
> 5. Flush
> 6. Await response and check for errors
> 7. Bind
> 8. Flush
> 9. Await response and check for errors
> 10. Execute
> 11. Flush
> 12. Await response and check for errors
> 13. Close portal
> 14. Flush
> 15. Await response and check for errors
> 16. Close statement
> 17. Flush
> 18. Await response and check for errors
> 
> However, while Pgpool-II forwards the Flush commands to the upstream PostgreSQL server, it buffers the ParseComplete and BindComplete responses despite the Flush. They never reach the downstream Skunk client, and the connection sits idle forever. The client duly awaits the response data and cannot proceed further, but it has no way to force Pgpool-II to send it. If I understand correctly, Pgpool-II is technically in the wrong here, as much as Skunk’s approach may not be the most efficient.
> 
> The same issue was observed with Describe back in March and worked around by forcing RowDescription messages to be flushed always:
> 
> https://git.postgresql.org/gitweb/?p=pgpool2.git;a=commitdiff;h=743a69b92d99020e3d1e479ad553a05c68b3b3cd;hp=e16b9f0d94d20bc295b2da439749b81b03a7b72f
> 
> However, this clearly affects more than just Describe.
> 
> (I can confirm that if I hack Skunk to send Parse and Describe together, it does receive the responses up to RowDescription and hangs waiting for BindComplete instead.)
> 
> I see the Pgpool-II TODO wiki page mentions Flush tracking.

I am thinking about to implement the flush tracking for the next
Pgpool-II major release.

> But until that is implemented, shouldn’t SimpleForwardToFrontend rather default to flushing *all* responses and have a list of specific exceptions that are allowed to be buffered because the protocol guarantees that they are followed by flushable messages?

I think the change is too risky for major applications such as JDBC in
term of performance degration. Instead of this, I have implemented
"simple" flush message tracking. It remebers there is a pending flush
request when a flush message is sent from client. When a response
message from backend is received, the response is flushed to
frontend. The limitation is that it only flushes last 1 reply
message. So,

Parse
Flush

will work as expected. Because Parse complete is flushed.

However

Parse
Bind
Flush

may not work as expected.

Parse
Bind
Flush

Parse complete is flushed but Bind complete may not be flushed.

What do you think?

Best reagards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: flush.patch
Type: text/x-patch
Size: 2012 bytes
Desc: not available
URL: <http://www.pgpool.net/pipermail/pgpool-general/attachments/20220109/7b9f3404/attachment.bin>