Closed johanneswuerbach closed 5 years ago
@johanneswuerbach Tests are failing...
Added a fix for the second race.
Can you explain the second one a little more? I’ve copied the simpler first one into a pull request at #111 in case it can go in earlier.
@charmander the issue occurs when you use connectionTimeoutMillis
and in the following situation:
connectionTimeoutMillis
and a failure returned to the clientMy fix now creates a pendingItem
object, which remembers the callback + timed out state and directly adds the new client to the idle queue in step 6 when the pending item already timed out.
Thanks for the explanation!
When will we see this merged?
@brianc any chance you could have a look? Happy to rebase, but I would prefer a general 👍 / 👎 first.
I think this looks good! Thanks for the explanation and PR! If you rebase I'll npm-link it into pg
and make sure the tests pass over there as well (they should, they don't exercise the pool as much as these do, but wanna be sure) and if everything looks good I'll release a new patch version.
@brianc done 👍
Let me also know, if you think https://github.com/brianc/node-pg-pool/pull/110 is worth-while proceeding :-)
K - tested this w/ node-postgres. All is in order. Will release a new patch version shortly. Thanks again!
@brianc Christmas-shortly by any chance? :smile: Throw it under the Christmas tree, will ya? :smile:
Ah crap i totally forgot to release this after i tested. Will do! Sorry!
When will it be? :)
bump for great justice.
Really appreciate all the hard work on the library -- this one's definitely impacting us in production. New tagged release would be 💯
Thank you!
yeah...sorry again. Was out of town. release pg-pool@2.0.6
Fix two races
can occur after any connection failure as another
_pulseQueue
is never started and pending items added during the connect won't be processedoccurs when a formerly queued client is processed and finds a free pool slot (e.g. because a previous client errored), but during client.connect times out itself.