Skip to content

pg-pool: don't allow connection reuse after streaming #2832

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

Conversation

alxndrsn
Copy link
Contributor

@alxndrsn alxndrsn commented Oct 5, 2022

This might be a fix for #1674.

I would expect that connections could be re-used safely after streaming though, so there should be a more correct way of approaching this...

@@ -331,7 +331,7 @@ class Pool extends EventEmitter {
client._poolUseCount = (client._poolUseCount || 0) + 1

// TODO(bmc): expose a proper, public interface _queryable and _ending
if (err || this.ending || !client._queryable || client._ending || client._poolUseCount >= this.options.maxUses) {
if (err || this.ending || !client._queryable || client._ending || client._poolUseCount >= this.options.maxUses || client?.activeQuery?.cursor) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This probably isn't the correct way to check if the activeQuery is a QueryStream, but using isntanceof doesn't seem appropriate: AFAICT there's currently no dependency from pg-pool -> pg-query-stream, and there probably shouldn't be.

@alxndrsn alxndrsn marked this pull request as ready for review October 5, 2022 15:17
Copy link
Collaborator

@charmander charmander left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn’t a good hack. I don’t think it should be merged.

@alxndrsn
Copy link
Contributor Author

alxndrsn commented Oct 6, 2022

@charmander thanks for the feedback, I don't disagree. If it was good, it wouldn't be a hack 😄

Does the test case look valid to you? Perhaps test/error.ts would be a more suitable location(?)

Do you have any suggestions on a more correct approach to fixing the issue?

@alxndrsn
Copy link
Contributor Author

alxndrsn commented Jul 5, 2023

Closing in favour of #2836.

@alxndrsn alxndrsn closed this Jul 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants