-
Notifications
You must be signed in to change notification settings - Fork 184
Extended flow queries hang with pgpool 4.1 #341
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
If you would like us to spend some time helping you to diagnose the problem, please spend some time describing it and, ideally, providing a minimal sample that reproduces the problem. |
this is demo https://github.com/lyxgy841/r2dbc-demo |
Thanks a lot. Here's an excerpt from the logs:
The conversation stops after the flush request (P/H). Looking at JDBC, the sequence consists of Parse, Bind, Desc, Execute, Sync (P/B/D/E/S). While we do not combine all packets, it looks like we should include |
Interestingly, this issue happens with PGPool 4.1 but not with PGPool 4.0.x. |
To achieve a similar flow as with PGJDBC, we would need to change our statement caching API in the way that we generate a statement name but do not await Paging @davecramer and @Squiry to verify my approach. |
Hi @mp911de, implementation 'org.springframework.boot.experimental:spring-boot-starter-data-r2dbc:0.1.0.M3'. I recently tried to upgrade to the latest available version of spring-boot-starter-data-r2dbc, r2dbc-pool, and r2dbc-postgresql and the problem persists. I hope that this additional information will help you in solving the problem. |
I had a look what it takes to make this work with pgpool 4.1. We need to rewrite our query flow and change conceptually how the statement cache works. Basically, the cache needs to supply only details and no more initiate the query parsing on its own. Beyond that, we're using an optimized flow with cursors that creates a cursor even in auto-commit mode. That is because we use That means we require a compatibility mode where we use I have got a working prototype locally, but it would be good to get some reviewers once I can submit a PR. |
I beleive I can help you with that. But that sounds like broken fetch size for a pgpool. |
I submitted #373 containing the changes. |
Hello, Do you know when will this fix be released? |
#373 needs more reviews first before we can go into planning. Other than that, you can find release dates in the milestones. |
Thanks for the heads up @mp911de ! |
We now support a compatibility mode for extended query flows. Enabling compatibility mode fetches all rows in auto-commit mode regardless the configured fetch size. Cursors are only used with explicit transactions and using Sync instead of Flush to work with newer pgpool versions. Compatibility mode is disabled by default to retain semantics of the previous driver version. [fixes #341][#373]
StatementCache now no longer prepares statements (Parse) itself but rather reports whether statement preparation is required. That allows to streamline message handling to combine multiple messages into a composite one to reduce the number of sent TCP packets. ExtendedFlowDelegate encapsulates the extended flow. [fixes #341][#373]
We now support a compatibility mode for extended query flows. Enabling compatibility mode fetches all rows in auto-commit mode regardless the configured fetch size. Cursors are only used with explicit transactions and using Sync instead of Flush to work with newer pgpool versions. Compatibility mode is disabled by default to retain semantics of the previous driver version. [fixes #341][#373]
That's fixed now. |
Bug Report
Versions
Current Behavior
I hava a PostgreSql cluster with Pgpool-II, other services connected to Pgpool using jdbc can run normally, but service using
r2dbc connect to pgpool, queries just hang forever.
The text was updated successfully, but these errors were encountered: