Conversation
There was a problem hiding this comment.
Kudos for digging into the performance and connection mgmt. issues with this library @bentsku ! 💪
Added a few initial comments - main question for me is the question of how to deal with the write events from the sockets. Let's proceed with testing the integration in RDS upstream, this should give us some more insights.. 👍
There was a problem hiding this comment.
Looks great @bentsku 🚀
Let's also bump the version in setup.py (perhaps this could become a minor version 0.1.0, as it contains some fairly significant changes in the logic, and also some small changes in the (internal) API). And would be great if we could start a short Changelog section in the README 👍
Will do 👍 (I had bumped to |
This PR adds some quality of life changes to the proxy, as well as optimisations concerning selector polling (the selector would burn some CPU as it was polling on
EVENT_WRITEwhich was always true. It would return every 1ms, now correctly wait for 1s timeout while selecting. The socket will manage if the redirected socket is writable, and if not, can always raise an error).It adds different checks in the lifecycle on the connection, and properly terminate Postgres side with a
Terminationmessage as described by the PostgreSQL documentation (https://www.postgresql.org/docs/current/protocol-message-formats.html#PROTOCOL-MESSAGE-FORMATS-TERMINATE) to follow the correct message flow. Sometimes the client would disconnected without sending it, which would let the Postgres side in aReadyForQuerystate, waiting to receive something which would never come.This came to light with this issue: prisma/prisma#11134
After reproducing locally, it seems the issue is now solved.