Race Condition Issue in PostgreSQL SSL Connection Process

从 lib/connection.js 开始，跟踪在通过 RDS Proxy 建立 PostgreSQL 连接期间，stream.connect()、TCP 'connect' 事件、requestSsl() 和 stream 的 'data' listener 如何协调工作。如果可能，重现间歇性的 TLS 断开，并将其与直接的 PostgreSQL 连接进行比较。完成标准是确认或否定竞态条件假设，并记录具体的缓解措施或修复方案。

I have been encountering "Error: Client network socket disconnected before secure TLS connection was established" errors recently without any specific cause when connecting to PostgreSQL through RDS Proxy. These errors occur intermittently, making them difficult to reproduce consistently.
After examining the code in the pg module's lib/connection.js file, I suspect there is a race condition issue between the TCP connection and TLS connection process. The architecture of the connection flow appears problematic:

• Client initiates TCP connection (stream.connect(port, host))
• When TCP connection succeeds, a 'connect' event is emitted
• However, the code for SSL/TLS connection is not directly linked to the 'connect' event
• Instead, logic to wait for the server's SSL support response is set up separately (stream.once('data', function (buffer) {...})

This design creates potential timing issues because:

• There's no explicit synchronization between the TCP connection establishment and when requestSsl() is called
• The SSL handshake process depends on event listeners that operate asynchronously
• When working with RDS Proxy as an intermediary layer, these timing sensitivities may become more problematic

I've verified this by testing direct connections to PostgreSQL without RDS Proxy, which work consistently. The issue only manifests when connecting through the proxy layer.
Please check if my understanding of this potential race condition is correct, and if there are any recommended approaches to mitigate this issue.