AWS RDS and Extended Query Protocol
See original GitHub issueHi! Amazing library, thanks for all of the hard work.
TLDR: The extended query protocol makes the AWS RDS Proxy entirely useless. Is there any way to turn off the extended query protocol in pg
?
I have a serious issue I’m facing in a serverless environment. I’m using AWS Lambda, and directly connecting to postgres has caused horrific performance and stability issues because of the vast numbers of connections being opened and closed. So, the solution from AWS seems to be to use their RDS Proxy. It sits in front of postgres and handles a warm connection pool. I’ve set it all up properly. Unfortunately, all of my connections are being session pinned, essentially rendering the proxy useless, and it even seems to be performing worse than without the proxy. I’ve looked at my error logs and found this error repeatedly:
The client session was pinned to the database connection [dbConnection=251482716] for the remainder of the session. The proxy can't reuse this connection until the session ends. Reason: A parse message was detected.
Reason: A parse message was detected.
. This seems to come because of the extended query protocol. Apparently the extended query protocol causes pinning, as documented here: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-proxy.html#rds-proxy-pinning
So my real question is, is there any way to turn off the extended query protocol in pg
? If not, does anyone have any insight into how I can properly manage connections to my database in a serverless environment? This is a major issue for us at this time, and I’m not sure how to proceed
Issue Analytics
- State:
- Created 3 years ago
- Reactions:1
- Comments:18 (3 by maintainers)
Top GitHub Comments
There is no difference at the protocol level, actually. Any query with parameters (whether or not you call it a prepared statement) requires a parse/bind/describe/execute series of messages. Either way it “prepares” the query during the parse phase. Sorry the RDS proxy is so picky about parameterized queries…that’s quite limiting as doing parameters in queries with string concatenation and client side sanitization is not ideal. Let me know if there’s anything you can think of from this libraries side to help…but sounds like an RDS issue for now.
@picosam I don’t really remember, I don’t work for that employer now and I’ve transitioned entirely into Web3. I think we created it outside of the handler, and I think we used a single connection, but really I don’t remember. I’m sure I did the most sensible way after trying out or researching many ways of doing it.