* Fix typo
* Enable eslint:recommended and remove unused eslint plugins
Enables eslint:recommended by disabling the options that would not pass. Also removes
dependencies for included but unused eslint plugins.
* Convert console.error(...) calls to use %s placeholders
* Enable eslint no-console rule
* Add and enable eslint-node-plugin
* Correct typo
* Enable eslint no-unused-vars
* Added the missing connect_timeout and keepalives_idle config parameters
* Implementation and tests for keepAliveInitialDelayMillis and connectionTimeoutMillis [squashed 4]
* Add tests for query callbacks after connection-level errors
* Ensure callbacks are executed for all queued queries after connection-level errors
Separates socket errors from error messages, sends socket errors to all queries in the queue, marks clients as unusable after socket errors.
This is not very pleasant but should maintain backwards compatibility…?
* Always call `handleError` asynchronously
This doesn’t match the original behaviour of the type errors, but it’s correct.
* Fix return value of `Client.prototype.query` in immediate error cases
* Mark clients with closed connections as unusable consistently
* Add tests for error event when connecting Client
* Ensure the promise and callback versions of Client#connect always have the same behaviour
* Give same error to queued queries as to active query when ending
and do so in the native Client as well.
* Restore original ordering between queued query callbacks and 'end' event
Defaults to built-in `tls.checkServerIdentity` method in the event one is not passed into `pgConfig.ssl`
Found breaking in v9.4.2 vs v9.4.1 a la 49054717b4ec0c6d477f04c2becd1f9680b2d13a
cc @tobio @brianc
This commit adds some finer grained detail to handling the postmaster's
response to SSL negotiation packets, by accounting for the possibility
of an 'E' byte being sent back, and emitting an appropriate error.
In the naive case, the postmaster will respond with either 'S' (proceed
with an SSL connection) or 'N' (SSL is not supported). However, the
current if statement doesn't account for an 'E' byte being returned
by the postmaster, where an error is encountered (perhaps unable to
fork due to being out of memory).
By adding this case, we can prevent confusing error messages when SSL is
enforced and the postmaster returns an error after successful SSL
connections.
This also brings the connection handling further in line with
libpq, where 'E' is handled similarly as of this commit:
a49fbaaf8d
Given that there are no longer pre-7.0 databases out in the wild, I
believe this is a safe change to make, and should not break backwards
compatibility (unless matching on error message content).
* Replace if statement with switch, to catch 'S', 'E' and 'N' bytes
returned by the postmaster
* Return an Error for non 'S' or 'N' cases
* Expand and restructure unit tests for SSL negotiation packets
The support for the `noAssert` argument dropped in the upcoming
Node.js v.10.x. All input is then validated no matter if this
is set to true or not. Just remove the argument because of that.
* Work on converting lib to standard
* Finish updating lib
* Finish linting lib
* Format test files
* Add .eslintrc with standard format
* Supply full path to eslint bin
* Move lint command to package.json
* Add eslint as dev dependency
* Remove unsupported Node versions 0.10 and 0.12 from CI
* Replace deprecated Buffer constructor with .from/.alloc
* Remove Promise polyfill
* Make use of Object.assign
* Remove checks for versions of Node earlier than 4
* Remove Buffer#indexOf fallback for Node 0.10
* Avoid infinite loop on malformed message
If handling of such messages is deemed unimportant, `indexOf` is still faster (~40%) and cleaner than a manual loop.
Addresses #1048 to an extent.
* Use indexOf fallback for Node ≤0.12
A long standing bug was the pure JS client didn't accept or call a callback on `client.end`. This is inconsistent with both the documentation & general node patterns.
This fixes the issue & adds a test. The issue did not exist in the native version of the client.
I noticed that query cancellation was not working when connecting through pgbouncer,
even though it worked fine when directly connected. This is because we're appending an
extra null byte, and pgbouncer is strict about the packet length.
(per http://www.postgresql.org/docs/9.1/static/protocol-message-formats.html)
This removes the extraneous byte, which fixes cancellation against pgbouncer.
Postgres has a 63 character limit on query names. To avoid potential footgunning of users we'll log to their stderr if they use a longer query name.
For reference: https://github.com/brianc/node-postgres/pull/772
a fix was provided in 5079c1e0c41f431ac2e02c40ebd875d8fbb34004;
test is modeled on query-error-handling-tests.js;
test both kill query and disconnection on prepared statement execution;
make connection error string message consistent between native and non-native;
disable test server-side kill for native as it hangs;
sync can cause error to be emitted so we catch that;
we also move _ending state before _send is called.
