Skip to content

Query error propagation #2

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
wants to merge 1 commit into from
Closed

Query error propagation #2

wants to merge 1 commit into from

Conversation

pshc
Copy link
Contributor

@pshc pshc commented Nov 2, 2010

This patch ensures that errors during query processing are emitted by the relevant Query object. Essential for error handling on the client side. Also it does a sync() so that the connection keeps going.

The problem with it is that errors will get emitted twice, once from Query and once from Client. Not sure what to do about that—maybe temporarily suspend the Client's error listener when a query is happening?

I also updated the relevant test, but I'm not 100% on it due to both the double-error business and the fact that the type coercion tests were failing either way. Not sure what's up with that.

Thanks for your trouble!

@brianc
Copy link
Owner

brianc commented Nov 2, 2010

I agree with what you're saying here and definitely think there needs to be a better error handling story. I haven't really put a lot of effort into the correct way to handle errors yet.

One thing though with this patch...I'm not sure you need to send a sync message to the server unless you're in the middle of processing a prepared statement when the error is encountered. What about hitting an error during a simple query? I think it might need a few more tests to ensure sync is only sent when it's needed. I was thinking of possibly writing a unit test or two using a "mock" stream to fake out when the errors come back. What you think?

If you check out `test/unit/client/prepared-statement-tests.js' there is an example of mocking out the prepared statement communication in there. I was thinking of adding "error" instead of the correct "Complete" response sometimes & checking for correct handling. I thought that might be easier than formulating a query which would correctly make PostgreSQL server throw an error at each step of the process.

Also: figured out what was going on w/ the type coercion tests. It had to do w/ the way I was loading a BUNCH of queries into the client's query queue and not waiting long enough for them to complete. Didn't show up until I tested on a slower machine. I've set up a really resource constrained linode instance now w/ NVM and PostgreSQL 8.4. So I can test against multiple versions of postgres and node. So...no more huge test failures hopefully! Sorry 'bout that.

@pshc
Copy link
Contributor Author

pshc commented Nov 2, 2010

I bet you're right about the synching. Didn't look at the spec closely enough. Mock stream sounds good. I'm familiarizing myself with your testing methods so I'll hopefully be writing more elaborate tests soon.

And that's what I get for developing on a netbook, ha!

@brianc
Copy link
Owner

brianc commented Nov 2, 2010

yah man that's awesome you caught those timing issues on the queries. I pushed out some more updates to the tests to fix the timing stuff. I got two way date coercion working, but I think it impacts performance somewhat cause you gotta do an "instanceof" to every single parameter in every query. :( Not sure of any way around it without forcing the coercion on the user.

Algunenano pushed a commit to Algunenano/node-postgres that referenced this pull request May 8, 2018
brianc added a commit that referenced this pull request Dec 20, 2019
brianc pushed a commit that referenced this pull request Dec 27, 2019
Prevent `generic-pool` error when releasing a client with an error.

Fixes #2
brianc pushed a commit that referenced this pull request Apr 28, 2020
Add supporting password with colon
This pull request was closed.
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