Charmander

@Cactusbone That’s probably going to be the [“statement-level load balancing”](https://www.pgpool.net/docs/latest/en/html/release-4-1-0.html). Indeed not related to this issue, and probably not related to node-postgres, so you don’t need to open another issue.

The pool removes clients pretty aggressively (e.g. even when the query error is an error in the query). Are you using `pool.query` or acquiring clients manually? What does the error...

It looks like a pg-promise bug to me. https://github.com/vitaly-t/pg-promise/blob/3d2c670af42e9e1d93d4dc23095061550b40a7c3/lib/database.js#L333 The connection is returned to the pool even if the query fails because the connection dropped.

> How is the condition incorrect? It’s missing `typeof`. > Regardless of your judgement on goodness or badness of extending built-in prototypes, users are going to, when they need to....

`Date` parameters are serialized as local time by default in current pg, with the timezone dropped when the parameter is interpreted as a `timestamp`. This is wrong (there’s no guarantee...

You can also go directly to `pg-connection-string` (which is [how pg parses `connectionString`](https://github.com/brianc/node-postgres/blob/373093d176f0ceb0266333680b20d0acf38004e3/packages/pg/lib/connection-parameters.js#L56)) and merge the resulting configuration exactly the way you want: ```js import parseConnectionString from 'pg-connection-string'; const pgConfig...

The tests aren’t currently written to be runnable with `PG*` environment variables. You might have better luck with `make test-all connectionString=postgres://localhost:5432/?sslmode=require`.

> @charmander any thoughts on this? I think it looks p great! If it’s going to be a separate package instead of an API change to pg’s default query type...

Thanks for bringing this up. Do you have any benchmark results?

20% faster on what benchmark?