Add option to time out pg.connect() call #1006
Conversation
|
Great job! Although I would have called it |
|
My worry about connect timeout is it has a really specific meaning, the amount of time before you give up on a CONNECT syscall. In this instance, I'd expect a connectTimeout to indicate the amount of time it took for a socket to be established to the remote database. see also https://curl.haxx.se/libcurl/c/CURLOPT_CONNECTTIMEOUT.html, http://docs.python-requests.org/en/master/user/advanced/#timeouts. |
Currently if you call pg.connect(), the call will block indefinitely until a connection becomes available. In many cases, if a connection is not available after some period of time, it's preferable to return an error (and call control) to the client, instead of tying up resources forever. Blocking on resource checkout also makes it easier for clients to deadlock - recently at Shyp, we had a situation where a row got locked and the thread that could unlock it was blocked waiting for a connection to become available, leading to deadlock. In that situation, it would be better to abort the checkout, which would have errored, but also broken the deadlock. Add a new setting to defaults: `acquireTimeout`, which will wait for `acquireTimeout` milliseconds before giving up and returning an error. If the value is undefined (the default), `node-postgres` will continue to wait indefinitely for a connection to become available. This builds on a pull request against `generic-pool`, support options.timeout: coopernurse/node-pool#127. Review has been slow going, so I published a new package with that change as `generic-pool-timeout`, and updated the reference in this codebase. Adds semicolons in many places that omitted them and fixes several typos. I'm happy to pull those out into a different commit. Sets the TZ=GMT environment variable before running the tests; without this value set, and with a Postgres server set to the America/Los_Angeles timezone, a timezone test failed. Fixes brianc#782 and brianc#805. Will help alleviate brianc#902. May help with brianc#397.
|
@kevinburke this is really fabulous - I appreciate you putting the time in here! I've recently returned from a long, dark time of not using node-postgres enough back into the beautiful world of lots of node + postgres work! I actually have had my eye on the issue of |
Sounds good to me. FWIW I am about to leave my company, and (probably) server side Javascript, but I'm happy to look at a patch if you send one! We've been running this in production for about three weeks now without any problems. |
|
IMHO this feature would be very very useful. For instance, I declared a pool of connections in my integration tests, in addition to the pool declared in the server, so the pool was not big enough. @kevinburke @brianc when can we expect this change to be available in node-pg-pool ? |
|
I would really appreciate this option. Can I somehow help to get this merged? |
|
+1 for this |
|
@brianc @charmander could you pleeeeeaaase look at this ? |
|
I think this has been implemented but in a different way - check out pg-pool
On Thu, Feb 23, 2017 at 08:43 Arnaud Benhamdine ***@***.***> wrote:
@brianc <https://github.com/brianc> @charmander
<https://github.com/charmander> could you pleeeeeaaase look at this ?
It would be so useful 😢
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1006 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAOSI4_1UDP03laP-ZVIqkfk7UyzM2BQks5rfbcdgaJpZM4IVIGk>
.
--
…--
Kevin Burke
925.271.7005 | kev.inburke.com
|
Could you elaborate ? |
|
pg-pool isn’t generic-pool, but pg-pool 1.x does still depend on generic-pool 2.x. |
Oups yes sorry you're right. However main point is that generic-pool 3.x is not used yet by pg. |
|
I think having a connection timeout is really important for production systems. Sorry for the delay in getting to this. I recently (as of last week) quit full-time work so I could focus a lot more time on this library. I added this to the 7.0 milestone which I intend to start working on at the beginning of next week! 💃 |
|
I've added this in |
Currently if you call pg.connect(), the call will block indefinitely until a
connection becomes available. In many cases, if a connection is not available
after some period of time, it's preferable to return an error (and call
control) to the client, instead of tying up resources forever.
Blocking on resource checkout also makes it easier for clients to deadlock -
recently at Shyp, we had a situation where a row got locked and the thread
that could unlock it was blocked waiting for a connection to become available,
leading to deadlock. In that situation, it would be better to abort the
checkout, which would have errored, but also broken the deadlock.
Add a new setting to defaults:
acquireTimeout, which will wait foracquireTimeoutmilliseconds before giving up and returning an error. If thevalue is undefined (the default),
node-postgreswill continue to waitindefinitely for a connection to become available.
This builds on a pull request against
generic-pool, support options.timeout:coopernurse/node-pool#127. Review has been slow going,
so I published a new package with that change as
generic-pool-timeout, andupdated the reference in this codebase.
Adds semicolons in many places that omitted them and fixes several typos. I'm
happy to pull those out into a different commit.
Sets the TZ=GMT environment variable before running the tests; without this
value set, and with a Postgres server set to the America/Los_Angeles timezone,
a timezone test failed.
Fixes #782 and #805. Will help alleviate #902. May help with #397.