"Client has encountered a connection error and is not queryable" without further info #1790
Comments
|
The reason will have been emitted as an |
|
hello I have a similar issue: I got a Pool that is not queryable and any error logged. I cant catch this error regardless of what I do. |
|
I'm having this problem too. In my case I am using version 7.7.1 with typeorm |
|
@charmander Ok thanks! Seems I just missed it in our application logs since it was logged several hours before the "Client has encountered a connection error and is not queryable" message in each case. Maybe it would make sense to include a copy of the reason along with the "Client has encountered a connection error and is not queryable" message, just for easier debugging? For the record, we're using TypeORM and a pool. Anyway, from our side, this issue can be closed. Thanks for the quick help! |
|
I also see this error with plain but it is emmited only once, while the in my case, the emmited error was in my case, this happened because of a network reset. |
|
@rvion I'm currently seeing a similar issue, the error "Connection terminated unexpectedly" has come up, afterwards the connection was not queryable anymore ("Client has encountered a connection error and is not queryable". May I ask how you approached this problem? |
|
How about adding a helper method for auto-reconnecting whenever this happens? |
Any update on this? |
This comment was marked as duplicate.
This comment was marked as duplicate.
|
I have this same issue. Should we create a new Client (or Pool) object on error or what? |
|
Apparently that's exactly what we should do. From #1611 (comment) (see post for more info) -- db = new pg.Client();
db.on('error', e => {
console.error('Database error', e);
db = null;
}); |
|
Starting with the above code snippet, here's what I've come up with: // db.js
let dbClient;
export const getDbClient = () => {
// TODO: How do I know dbClient is any good? <---
return dbClient;
}
const reconnectToDb = async () => {
dbClient = null;
dbClient = await createDbClient();
}
const createDbClient = async () => {
const client = new Client({
connectionString: "..."
});
client.on('error', err => {
console.error('Postgres error:', err.stack);
reconnectToDb();
});
await client.connect();
console.log('Successfully connected to Postgres');
return client;
};
(async () => {
await reconnectToDb();
})()// Doing Postgres queries
const result = await getDbClient().query("...")It works great in most ways -- my server doesn't crash, and after there's an error querying Postgres the client automatically reconnects -- but ideally I would know that my next query isn't going to work and create a new DB connection (see the TODO toward the top of this post). EDIT: Ideally I could do |
|
It would be convenient to know what note is causing troubles. I see the failures in the logs of the DB: at that point we are ok then the sync starts. I see no error in the server logs but the resource ID can be seen there as the PUT fails: |
|
I forgot to mention that I ran into this issue with attachments over 100MB whereas my initial limit was set to 100MB (so totally expected issues). After seeing this, I bumped the limit to 200MB. |
|
Spotting the resource ID in the logs, I could delete the faulty attachement using the "tools/note attachments" and the issue is solved. I could reproduce the issue by adding the attachment again to the note: a 130MB audio recording in MP3 format. |
|
This happens if there's a background error with the connection... i.e., one that isn't tied to a If something like idle in transaction timeout happens, there might be an error raised outside of a client.query.... this will get emitted as an error event on client, and pool. (unhandled error events will crash the process) Refer to docs: https://node-postgres.com/apis/client#error -- specifically, " due to network partitions, back-end crashes, fail-overs, etc the client can (and over a long enough time period will) eventually be disconnected while it is idle" If you try to use -- Also, felt I shouuld comment on @chevdor 's message, specifically highlighting this: Someone kill -9'd your database ... postgres really doesn't like when you do that which is why it said it was in recovery mode. If you have a Best way to handle that is use Pool ... this keeps a series of clients, most of them will be in a diconnected state until they are needed, then they'll be reused. If a timeout is reached (default 10 seconds) it'll disconnect and go away. Next pool.connect will return the first connected non-idle client, or create a new connection if none exist. Some orms might add
And the nodejs process will absolutely crash if an unhandled error event bubbles up without getting caught. |
This comment was marked as off-topic.
This comment was marked as off-topic.
Since upgrading from pg 7.4.1 to pg 7.7.1, we are getting "Client has encountered a connection error and is not queryable" error in production after a week of working just fine, but no additional information is being logged that could help us determine what the underlying issue is.
I believe this may have been caused by the changes in 3828aa8.
Expected behavior: also log the error reason.
The text was updated successfully, but these errors were encountered: