Fix client_encoding setting to support pg_bouncer when using libpq (#270)

[Hebo]

Fix for #270

The same change needs to be made when using the native driver as with the JS driver.

[strk]

This one seems good to me, please merge.

[brianc]

👍

[brianc]

@Hebo thanks so much.

[iToto]

Hey guys, just as a FYI, this change broke my app that's currently hosted on Heroku. Funny thing is the issue only arose when I deployed to Heroku. Locally it works fine...

Here's a dump of the log:

2013-06-03T03:22:54.836472+00:00 app[web.1]: Error: invalid connection option "client_encoding"
2013-06-03T03:22:54.836472+00:00 app[web.1]:
2013-06-03T03:22:54.836472+00:00 app[web.1]:     at Connection.<anonymous> (/app/node_modules/pg/lib/native/index.js:188:17)
2013-06-03T03:22:54.836472+00:00 app[web.1]:     at Connection.EventEmitter.emit (events.js:95:17)
2013-06-03T03:22:54.836472+00:00 app[web.1]:     at /app/node_modules/pg/lib/native/index.js:49:19
2013-06-03T03:22:54.836472+00:00 app[web.1]:     at /app/node_modules/pg/lib/connection-parameters.js:68:12
2013-06-03T03:22:54.836472+00:00 app[web.1]:     at asyncCallback (dns.js:68:16)
2013-06-03T03:22:54.836472+00:00 app[web.1]:     at Object.onanswer [as oncomplete] (dns.js:121:9)
2013-06-03T03:22:56.386049+00:00 heroku[web.1]: Process exited with status 8
2013-06-03T03:22:56.405519+00:00 heroku[web.1]: State changed from starting to crashed

[strk]

I guess a quick fix would be to make encoding setting optional,
but recommend that installer should make sure it is utf8 somehow.

[brianc]

Yeah I was thinking of only passing it into postgres if you hard set it explicitly on your connection parameters. Funny how small changes like this break the hell out of so many things. So it goes.

[brianc]

@iToto possible to open an issue with steps to reproduce?

[Hebo]

Does the javascript driver have this same issue? The change should bring the native connection options up to parity with the JS ones.

I've seen this error when using libpq v8.4, as the client_encoding option seems to have been added around 9.1.

[badave]

This was crashing our app on heroku as well. Downversioning to 1.0.x has temporarily fixed the issue on Heroku, but some of our devs are having an issue with the 1.0.x version locally.

[brianc]

@badave your app is crashing in heroku now? Which version of node-postgres are you using? Using native driver or javascript?

[badave]

Hey Brian,  the minor patch I submitted yesterday fixed this problem.  Making client encoding optional allowed us to take out specfying it to postgres altogether, which is what had broken versions 1.1-1.2 for us.  Currently our heroku boxes are happy with the latest version.
—
Sent from Mailbox for iPhone

On Fri, Jun 7, 2013 at 9:48 AM, Brian C [email protected] wrote:

@badave your app is crashing in heroku now? Which version of node-postgres are you using? Using native driver or javascript?

Reply to this email directly or view it on GitHub:
#356 (comment)

[brianc]

okay sweet.

[iToto]

sorry @brianc, didn't see this till today. However, I can confirm that my app is stable on heroku on version 2.0.0.

Keep up the awesome work! 👍

[brianc]

no problemo! Keep in mind the type parsing changes in v2.0. I'll put
together a backwards compatiblity plugin module on npm soon if you're not
interested in bigint and numeric/decimal coming out as text. This
actually sucks kind of because now COUNT() results are strings (the
function return type is bigint) even though you will likely never, ever,
ever have more than a few billion rows in your table.

On Mon, Jul 1, 2013 at 9:13 PM, iToto [email protected] wrote:

sorry @brianc https://github.com/brianc, didn't see this till today.
However, I can confirm that my app is stable on heroku on version 2.0.0.

Keep up the awesome work! [image: 👍]

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/356#issuecomment-20322612
.

[iToto]

I don't think I'll be effected by that change. Thanks though