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

Oleg Oshmyan 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:

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:


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?

Best regards,
Oleg Oshmyan

More information about the pgpool-general mailing list