archive-gh-me/node-postgres
1
0
Fork 0
mirror of https://github.com/brianc/node-postgres.git synced 2025-12-08 20:16:25 +00:00
Code Issues Projects Releases Wiki Activity

Update comments

Browse Source
This commit is contained in:
Brian M. Carlson 2020-10-08 10:39:32 -05:00
parent 73b940a1e2
commit 7f06bc062e
1 changed files with 5 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
packages/pg/lib/query.js
View File

@ -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