Error: connect ECONNREFUSED

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]

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.

[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.