Skip to content

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

Closed
lyxgy841 opened this issue Oct 20, 2020 · 13 comments
Closed

Extended flow queries hang with pgpool 4.1 #341

lyxgy841 opened this issue Oct 20, 2020 · 13 comments
Assignees
Labels
type: task A general task
Milestone

Comments

@lyxgy841
Copy link

lyxgy841 commented Oct 20, 2020

Bug Report

Versions

  • Driver: 0.8.5.RELEASE
  • Database: postgreSQL cluster with pgpool 4.1 (pgpool 4.0 works)
  • Java: jdk8
  • OS: win10

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.

@lyxgy841 lyxgy841 added the status: waiting-for-triage An issue we've not yet triaged label Oct 20, 2020
@mp911de
Copy link
Collaborator

mp911de commented Oct 20, 2020

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.

@lyxgy841
Copy link
Author

@mp911de mp911de added type: bug A general bug and removed status: waiting-for-triage An issue we've not yet triaged labels Nov 4, 2020
@mp911de
Copy link
Collaborator

mp911de commented Nov 4, 2020

Thanks a lot. Here's an excerpt from the logs:

2020-11-04 14:59:13.678 DEBUG 45353 --- [actor-tcp-nio-9] i.r.p.client.ReactorNettyClient          : [cid: 0x6][pid: 1307] Response: ReadyForQuery{transactionStatus=IDLE}
2020-11-04 14:59:13.743 DEBUG 45353 --- [           main] io.r2dbc.postgresql.PARAM                : [cid: 0x6][pid: 1307] Bind parameter [0] to: Dave
2020-11-04 14:59:13.745 DEBUG 45353 --- [           main] io.r2dbc.postgresql.PARAM                : [cid: 0x6][pid: 1307] Bind parameter [1] to: Matthews
2020-11-04 14:59:13.749 DEBUG 45353 --- [           main] i.r.p.client.ReactorNettyClient          : [cid: 0x6][pid: 1307] Request:  [Parse{name='S_0', parameters=[1043, 1043], query='INSERT INTO customer (firstname, lastname) VALUES ($1, $2) RETURNING *'}, Flush{}]

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 Sync. Going to test that.

@mp911de
Copy link
Collaborator

mp911de commented Nov 4, 2020

Interestingly, this issue happens with PGPool 4.1 but not with PGPool 4.0.x.

@mp911de mp911de added status: waiting-for-triage An issue we've not yet triaged and removed type: bug A general bug labels Nov 4, 2020
@mp911de mp911de changed the title Connection to pgpool, r2dbc database queries just hang forever Extended flow queries hang with pgpool 4.1 Nov 4, 2020
@mp911de
Copy link
Collaborator

mp911de commented Nov 4, 2020

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 ParseComplete before continuing with the flow. Instead, we should get hold of the parse message to append bind, desc etc.. We would have to register the prepared statement only when we receive ParseComplete.

Paging @davecramer and @Squiry to verify my approach.

@m4tt87
Copy link

m4tt87 commented Nov 16, 2020

Hi @mp911de,
I found the same problem in the past. To solve it, only as a workaround, I used the following dependencies:

implementation 'org.springframework.boot.experimental:spring-boot-starter-data-r2dbc:0.1.0.M3'.
implementation 'io.r2dbc:r2dbc-pool:0.8.0.RELEASE'.
implementation 'io.r2dbc:r2dbc-postgresql:0.8.0.RELEASE'.
Any subsequent version of the libraries above caused the problem.
PGPool version: 4.1.4

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.

@mp911de mp911de added type: task A general task and removed status: waiting-for-triage An issue we've not yet triaged labels Dec 14, 2020
@mp911de mp911de self-assigned this Dec 14, 2020
@mp911de
Copy link
Collaborator

mp911de commented Dec 16, 2020

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 Execute + Flush instead of Execute + Sync. That works pretty well when using a Postgres server directly. Pgpool fails to respond since version 4.1.

That means we require a compatibility mode where we use Execute + Sync. It's a pretty significant change. While the compatibility mode aligns with what PGJDBC does, we should not enable compatibility mode by default.

I have got a working prototype locally, but it would be good to get some reviewers once I can submit a PR.

@Squiry
Copy link
Collaborator

Squiry commented Dec 17, 2020

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.

@mp911de
Copy link
Collaborator

mp911de commented Dec 18, 2020

I submitted #373 containing the changes.

@dave-b-uk
Copy link

Hello,

Do you know when will this fix be released?

@mp911de
Copy link
Collaborator

mp911de commented Jan 5, 2021

#373 needs more reviews first before we can go into planning. Other than that, you can find release dates in the milestones.

@dave-b-uk
Copy link

Thanks for the heads up @mp911de !

mp911de added a commit that referenced this issue Feb 18, 2021
[fixes #341][#373]
mp911de added a commit that referenced this issue Feb 18, 2021
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]
mp911de added a commit that referenced this issue Feb 18, 2021
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]
mp911de added a commit that referenced this issue Feb 18, 2021
[fixes #341][#373]
mp911de added a commit that referenced this issue Feb 18, 2021
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]
@mp911de mp911de added this to the 0.8.7.RELEASE milestone Feb 18, 2021
@mp911de mp911de reopened this Feb 18, 2021
@mp911de
Copy link
Collaborator

mp911de commented Feb 18, 2021

That's fixed now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: task A general task
Projects
None yet
Development

No branches or pull requests

5 participants