The pool destroys the client with queued queries to it #632

Activity

1. booo commented on Aug 27, 2014

   

   booo

   on Aug 27, 2014

   Contributor

   More actions

   Could you please be a bit more specific? If possible provide example code. Thanks a lot.
2. brianc commented on Sep 3, 2014

   

   brianc

   on Sep 3, 2014

   Owner

   More actions

   You should not be returning a client to the pool before it's internal queue is done draining or while it still has pending work to do. While the API doesn't specifically prevent this with an exception this it's definitely not an intended usage pattern.
3. brianc

   closed this as completedon Sep 3, 2014
4. grudzinski commented on Sep 3, 2014

   

   grudzinski

   on Sep 3, 2014

   Author

   More actions

   When we call connect method on pg it returns one of client instances from its pool, then when we call query method on the client instance the query may be queued inside of the client instance if the client instance executes another query. If an error occurs in the client instance then pg destroys the client, but does not care about queued queries inside of it.

   pg.connect(function(err, client, done) {
   
       if (err) {
           console.error(err);
           return;
       }
   
       client.query('SELECT 1 + 1', function(err) { // may be queued
   
           // #1
   
           // An client connection error leaks here, user's code
           // now forced to care about this pg internal error
   
           // How to check if it is a pg internal error or an user error (SELECT 1 / 0)?
           // Why user should care about the pg internal error?
   
           if (err) {
               done(err); // will cause pg to destroy the client
           }
   
       });
   
       // Now shutdown pg server while first query executing, it will
       // cause a connection error
   
       client.query('SELECT 2 + 2', function(err) { // will be queued
   
           // #2
   
           // the callback will not be called
   
       });
   
   });
5. aviramst commented on Sep 3, 2014

   

   aviramst

   on Sep 3, 2014

   More actions

   Why did you call handleError of the active query if the error comes from the connection?
   How can my code handle connection errors?

     con.on('error', function(error) {
       if(self.activeQuery) {
         var activeQuery = self.activeQuery;
         self.activeQuery = null;
         return activeQuery.handleError(error, con);
       }
       if(!callback) {
         return self.emit('error', error);
       }
       callback(error);
       callback = null;
     });
6. brianc

   reopened this on Sep 3, 2014
7. brianc commented on Sep 3, 2014

   

   brianc

   on Sep 3, 2014

   Owner

   More actions

   @aviramst if you're running a query & you have a callback on the query we made the decision to bubble up a connection error to the query so you can handle it in the callback. Technically your query has failed if the connection dies.

   @grudzinski i see what you're saying now - valid point. Any client that's destroyed by the pool should have its query queue cleared out, certainly.
8. charmander

   added

   bug

   on Feb 16, 2017
9. charmander commented on Dec 2, 2018

   

   charmander

   on Dec 2, 2018

   Collaborator

   More actions

   Fixed in v7.5.0.
10. charmander

    closed this as completedon Dec 2, 2018