Node-postgres: Error: connect ECONNREFUSED

[udf2457]

Hi,

Not sure if this is a bug or unsupported, but I'm seeing the following error:

Error: connect ECONNREFUSED DBX:5342
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1113:14)

I'm calling pg on this basis:

        const pool = new Pool ({
            user: pgUser,
            password:pgPass,
            database:pgDb,
            host:pgHost,
            port:pgPort
        });

psql -U pgUser -d pgDb -h pgHost -W works fine and my pg_hba.conf is correctly configured:
host pgDb pgUser 10.0.0.0/8 md5

So I don't think its an issue with my postgres setup ?

Node v10.14.1
Postgres 9.6.11
Pg 7.7.1

[leventov]

Dear node-postgres maintainers, what do you think about special treatment of ECONNREFUSED: treating this as an error that PgPool should retry upon during connect()? This problem arises when starting up postgres and other containers in docker-compose, unfortunately docker-compose has removed readiness checks so it's not possible to solve this problem on docker-compose level.

[leventov]

If anyone stumbles upon this problem, I use the following wrapper as a workaround:

const pgPool = new Pool(pgConfig);
const pgPoolWrapper = {
    async connect() {
        for (let nRetry = 1; ; nRetry++) {
            try {
                const client = await pgPool.connect();
                if (nRetry > 1) {
                    console.info('Now successfully connected to Postgres');
                }
                return client;
            } catch (e) {
                if (e.toString().includes('ECONNREFUSED') && nRetry < 5) {
                    console.info('ECONNREFUSED connecting to Postgres, ' +
                        'maybe container is not ready yet, will retry ' + nRetry);
                    // Wait 1 second
                    await new Promise(resolve => setTimeout(resolve, 1000));
                } else {
                    throw e;
                }
            }
        }
    }
};

But I think this is a library's job.

[brianc]

But I think this is a library's job.

I definitely agree it can be __a__ library's job; however, I'm not sure we need to add it directly to _this_ library. You could have a wait-for-postgres npm module that does the above function or some other stuff _on top of pg_ that figures this out for you. I have felt this pain as well...I did a wait check in a jest global setup function so I'd be interested in a module that would take care of some of that stuff too!

The thing w/ adding it directly here is it's not useful in _every_ situation, and there are edge cases around how to report errors? Do we do exponential backoff? etc - those type of things very from app to app, and having it in it's own module allows it to be more elaborate w/o the impact of complicating core pg code which I'm trying to focus on perf and stability, not additional features which can be added outside the core modules.

[leventov]

pg-pool promises to reconnect on connection failures. In the case of ECONNREFUSED, it doesn't fulfil this promise.

To me, it feels that adding this functionality directly to the pg module is practical and user-friendly. You can also perhaps call this behavior stable (in the sense "reliable"), which you mentioned as the focus.

It's not useful in every situation

Could you please give an example of a situation when this addition is not useful and is harmful in any way?

By default, I think,

• "How to report errors?" - the same way as PgPool reports other errors now (which it promises to reconnect upon), that is, not reporting them, just consuming silently (or is there reporting on debug level which I don't see? I don't know.)
• "Do we do exponential backoff?" - I believe the simple scheme with a few attempts to reconnect with a fixed interval should fix 99% cases where this problem arises. If anyone needs anything different, e. g. infinite backoff, they could add it on top of PgPool still, just like in the code that I posted above.

[brianc]

I think auto-reconnection is something best handled by a higher level,
wrapping module for the time being. I may at some point in the future
consider adding it, but its low on my priority list.

On Tue, Feb 25, 2020 at 2:17 AM Roman Leventov [e-mail]
wrote:

pg-pool promises to reconnect on connection failures. In the case of
ECONNREFUSED, it doesn't fulfil this promise.

To me, it feels that adding this functionality directly to the pg module
is practical and user-friendly. You can also perhaps call this
behavior stable (in the sense "reliable"), which you mentioned as the
focus.

It's not useful in every situation

Could you please give an example of a situation when this addition is not
useful and is harmful in any way?

By default, I think,

• "How to report errors?" - the same way as PgPool reports other
  errors now (which it promises to reconnect upon), that is, not reporting
  them, just consuming silently (or is there reporting on debug level which I
  don't see? I don't know.)
• "Do we do exponential backoff?" - I believe the simple scheme with a
  few attempts to reconnect with a fixed interval should fix 99% cases where
  this problem arises. If anyone needs anything different, e. g. infinite
  backoff, they could add it on top of PgPool still, just like in the
  code that I posted above.

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
https://github.com/brianc/node-postgres/issues/1789?email_source=notifications&email_token=AAAMHIORYQHC22LXVX3SK2TRETHX7A5CNFSM4GKFD5T2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEM27X4A#issuecomment-590740464,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAMHILRAZ6I5ZGCW4P5UBDRETHX7ANCNFSM4GKFD5TQ
.