From 7f06bc062e99b989316cdf4cb0d63029d93c1e2e Mon Sep 17 00:00:00 2001 From: "Brian M. Carlson" Date: Thu, 8 Oct 2020 10:39:32 -0500 Subject: [PATCH] Update comments --- packages/pg/lib/query.js | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/packages/pg/lib/query.js b/packages/pg/lib/query.js index 514185eb..7214eaa3 100644 --- a/packages/pg/lib/query.js +++ b/packages/pg/lib/query.js @@ -136,11 +136,12 @@ class Query extends EventEmitter { this.emit('end', this._results) } - // in postgres 9.6 the backend sends both a command complete and error response - // to a query which has timed out on rare, random occasions. If we send sync twice we will receive - // to 'readyForQuery' events. I think this might be a bug in postgres 9.6, but I'm not sure... + // In postgres 9.x & 10.x the backend sends both a CommandComplete and ErrorResponse + // to the same query when it times out due to a statement_timeout on rare, random occasions. If we send sync twice we will receive + // to ReadyForQuery messages . I hink this might be a race condition in some versions of postgres, but I'm not sure... // the docs here: https://www.postgresql.org/docs/9.6/protocol-flow.html#PROTOCOL-FLOW-EXT-QUERY - // say "Therefore, an Execute phase is always terminated by the appearance of exactly one of these messages: CommandComplete, EmptyQueryResponse (if the portal was created from an empty query string), ErrorResponse, or PortalSuspended." + // say "Therefore, an Execute phase is always terminated by the appearance of exactly one of these messages: + // CommandComplete, EmptyQueryResponse (if the portal was created from an empty query string), ErrorResponse, or PortalSuspended." maybeSync(connection) { if (this.isPreparedStatement && !this._hasSentSync) { this._hasSentSync = true