[pgpool-general: 7967] Hang with Skunk because Flush not honoured
chortos at inbox.lv
Sat Jan 8 03:11:04 JST 2022
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:
3. Await response and check for errors
4. Describe statement
6. Await response and check for errors
9. Await response and check for errors
12. Await response and check for errors
13. Close portal
15. Await response and check for errors
16. Close statement
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:
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. 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?
More information about the pgpool-general