You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- echo -e "# TYPE DATABASE USER ADDRESS METHOD \nlocal all postgres trust\nlocal all all trust\nhost all all 127.0.0.1/32 trust" | sudo tee /etc/postgresql/$POSTGRESQL_VERSION/main/pg_hba.conf
Copy file name to clipboardExpand all lines: CHANGELOG.md
+14Lines changed: 14 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -4,6 +4,20 @@ For richer information consult the commit log on github with referenced pull req
4
4
5
5
We do not include break-fix version release in this file.
6
6
7
+
### v6.4.0
8
+
9
+
- Add support for passing `client_encoding` as a connection parameter. Used when decoding strings in the JavaScript driver. The default is still `utf8`.
10
+
11
+
### v6.3.0
12
+
13
+
- Deprecate `pg.connect``pg.end` and `pg.cancel` - favor using `new pg.Pool()` instead of pg singleton.
14
+
- Deprecate undocumented but possibly used `query.promise()` method. Use the promise returned directly from `client.query` / `pool.query`.
15
+
- Deprecate returning an automatically created query result from `client.query`. Instead return more idomatic responses for callback/promise methods.
16
+
17
+
### v6.2.0
18
+
19
+
- Add support for [parsing `replicationStart` messages](https://github.com/brianc/node-postgres/pull/1271/files).
20
+
7
21
### v6.1.0
8
22
9
23
- Add optional callback parameter to the pure JavaScript `client.end` method. The native client already supported this.
2. Borrowing a client from a pool and executing the query with it
22
+
3. Obtaining an exclusive client and executing the query with it
22
23
23
-
// instantiate a new client
24
-
// the client will read connection information from
25
-
// the same environment variables used by postgres cli tools
26
-
var client =newpg.Client();
24
+
It is recommended to pass the query to a pool as often as possible. If that isn't possible, because of long and complex transactions for example, borrow a client from a pool. Just remember to initialize the pool only once in your code so you maximize reusability of connections.
27
25
28
-
// connect to our database
29
-
client.connect(function (err) {
30
-
if (err) throw err;
26
+
### Why pooling?
31
27
32
-
// execute a query on our database
33
-
client.query('SELECT $1::text as name', ['brianc'], function (err, result) {
34
-
if (err) throw err;
28
+
If you're working on something like a web application which makes frequent queries you'll want to access the PostgreSQL server through a pool of clients. Why? For one thing, there is ~20-30 millisecond delay (YMMV) when connecting a new client to the PostgreSQL server because of the startup handshake. Furthermore, PostgreSQL can support only a limited number of clients...it depends on the amount of ram on your database server, but generally more than 100 clients at a time is a __very bad thing__. :tm: Additionally, PostgreSQL can only execute 1 query at a time per connected client, so pipelining all queries for all requests through a single, long-lived client will likely introduce a bottleneck into your application if you need high concurrency.
With that in mind we can imagine a situation where you have a web server which connects and disconnects a new client for every web request or every query (don't do this!). If you get only 1 request at a time everything will seem to work fine, though it will be a touch slower due to the connection overhead. Once you get >100 simultaneous requests your web server will attempt to open 100 connections to the PostgreSQL backend and :boom: you'll run out of memory on the PostgreSQL server, your database will become unresponsive, your app will seem to hang, and everything will break. Boooo!
38
31
39
-
// disconnect the client
40
-
client.end(function (err) {
41
-
if (err) throw err;
42
-
});
43
-
});
44
-
});
32
+
__Good news__: node-postgres ships with built in client pooling. Client pooling allows your application to use a pool of already connected clients and reuse them for each request to your application. If your app needs to make more queries than there are available clients in the pool the queries will queue instead of overwhelming your database & causing a cascading failure. :thumbsup:
45
33
46
-
```
34
+
node-postgres uses [pg-pool](https://github.com/brianc/node-pg-pool.git) to manage pooling. It bundles it and exports it for convenience. If you want, you can `require('pg-pool')` and use it directly - it's the same as the constructor exported at `pg.Pool`.
47
35
48
-
### Client pooling
36
+
It's __highly recommended__ you read the documentation for [pg-pool](https://github.com/brianc/node-pg-pool.git).
49
37
50
-
If you're working on something like a web application which makes frequent queries you'll want to access the PostgreSQL server through a pool of clients. Why? For one thing, there is ~20-30 millisecond delay (YMMV) when connecting a new client to the PostgreSQL server because of the startup handshake. Furthermore, PostgreSQL can support only a limited number of clients...it depends on the amount of ram on your database server, but generally more than 100 clients at a time is a __very bad thing__. :tm: Additionally, PostgreSQL can only execute 1 query at a time per connected client, so pipelining all queries for all requests through a single, long-lived client will likely introduce a bottleneck into your application if you need high concurrency.
38
+
[Here is an up & running quickly example](https://github.com/brianc/node-postgres/wiki/Example)
51
39
52
-
With that in mind we can imagine a situation where you have a web server which connects and disconnects a new client for every web request or every query (don't do this!). If you get only 1 request at a time everything will seem to work fine, though it will be a touch slower due to the connection overhead. Once you get >100 simultaneous requests your web server will attempt to open 100 connections to the PostgreSQL backend and :boom: you'll run out of memory on the PostgreSQL server, your database will become unresponsive, your app will seem to hang, and everything will break. Boooo!
40
+
For more information about `config.ssl` check [TLS (SSL) of nodejs](https://nodejs.org/dist/latest-v4.x/docs/api/tls.html)
53
41
54
-
__Good news__: node-postgres ships with built in client pooling. Client pooling allows your application to use a pool of already connected clients and reuse them for each request to your application. If your app needs to make more queries than there are available clients in the pool the queries will queue instead of overwhelming your database & causing a cascading failure. :thumbsup:
42
+
### Pooling example
43
+
44
+
Let's create a pool in `./lib/db.js` which will be reused across the whole project
55
45
56
46
```javascript
57
-
var pg =require('pg');
47
+
constpg=require('pg');
58
48
59
49
// create a config to configure both pooling behavior
60
50
// and client options
@@ -70,18 +60,63 @@ var config = {
70
60
idleTimeoutMillis:30000, // how long a client is allowed to remain idle before being closed
71
61
};
72
62
73
-
74
63
//this initializes a connection pool
75
64
//it will keep idle connections open for 30 seconds
76
65
//and set a limit of maximum 10 idle clients
77
-
var pool =newpg.Pool(config);
66
+
constpool=newpg.Pool(config);
67
+
68
+
pool.on('error', function (err, client) {
69
+
// if an error is encountered by a client while it sits idle in the pool
70
+
// the pool itself will emit an error event with both the error and
71
+
// the client which emitted the original error
72
+
// this is a rare occurrence but can happen if there is a network partition
73
+
// between your application and the database, the database restarts, etc.
74
+
// and so you might want to handle it and at least log it out
node-postgres uses [pg-pool](https://github.com/brianc/node-pg-pool.git) to manage pooling. It bundles it and exports it for convenience. If you want, you can `require('pg-pool')` and use it directly - it's the same as the constructor exported at `pg.Pool`.
133
+
For more examples, including how to use a connection pool with promises and async/await see the [example](https://github.com/brianc/node-postgres/wiki/Example) page in the wiki.
109
134
110
-
It's __highly recommended__ you read the documentation for [pg-pool](https://github.com/brianc/node-pg-pool.git).
135
+
### Obtaining an exclusive client, example
111
136
137
+
```js
138
+
var pg =require('pg');
112
139
113
-
[Here is an up & running quickly example](https://github.com/brianc/node-postgres/wiki/Example)
140
+
// instantiate a new client
141
+
// the client will read connection information from
142
+
// the same environment variables used by postgres cli tools
143
+
var client =newpg.Client();
144
+
145
+
// connect to our database
146
+
client.connect(function (err) {
147
+
if (err) throw err;
114
148
149
+
// execute a query on our database
150
+
client.query('SELECT $1::text as name', ['brianc'], function (err, result) {
151
+
if (err) throw err;
115
152
116
-
For more information about `config.ssl` check [TLS (SSL) of nodejs](https://nodejs.org/dist/latest-v4.x/docs/api/tls.html)
@@ -183,6 +230,10 @@ Information about the testing processes is in the [wiki](https://github.com/bria
183
230
184
231
Open source belongs to all of us, and we're all invited to participate!
185
232
233
+
## Troubleshooting and FAQ
234
+
235
+
The causes and solutions to common errors can be found among the [Frequently Asked Questions(FAQ)](https://github.com/brianc/node-postgres/wiki/FAQ)
236
+
186
237
## Support
187
238
188
239
If at all possible when you open an issue please provide
@@ -202,7 +253,7 @@ Follow me [@briancarlson](https://twitter.com/briancarlson) to keep up to date.
0 commit comments