Analysis: DBeaver Connection Timeouts to PostgreSQL 18 on Linux

Summary

This thread is a support request mistakenly posted to pgsql-hackers (the development mailing list), not a development discussion. It involves a user experiencing intermittent connection failures when using DBeaver to connect to a new PostgreSQL 18 production server running on Linux. The thread contains no patches, no architectural proposals, and no changes to PostgreSQL internals. It is notable primarily as an example of a common operational issue being misdirected to the wrong venue.

Core Problem

The reported issue is:

• A new Linux production PostgreSQL 18 server in a high-availability configuration (with a standby) experiences intermittent connection failures from DBeaver clients.
• Connections succeed approximately 1 in 3-4 attempts.
• PostgreSQL server logs show "broken pipe" errors, and clients see timeout errors.
• The same DBeaver tool works reliably against a Windows-based development server.
• Basic network connectivity (telnet) works fine from the command line.
• max_connections is set to 300 with minimal traffic, ruling out connection exhaustion.

Technical Analysis

Likely Causes (Not Explored in Thread)

The broken pipe errors in PostgreSQL logs indicate that the server attempted to write to a client connection that had already been closed from the client side. This typically means:

1. Network infrastructure issue: A firewall, load balancer, or NAT device between DBeaver clients and the PostgreSQL server is dropping or resetting TCP connections. This is the most common cause of intermittent "works sometimes" connection patterns.

2. TCP keepalive misconfiguration: If there's a stateful firewall with aggressive connection timeout settings, and PostgreSQL's tcp_keepalives_idle, tcp_keepalives_interval, and tcp_keepalives_count parameters aren't tuned to keep connections alive through it, idle connections may be silently dropped.

3. SSL/TLS handshake timeout: If SSL is enabled on the Linux server but not on the Windows dev server, and there's a latency or MTU issue, the SSL handshake may be timing out intermittently.

4. pg_hba.conf authentication method: If the Linux server uses a different authentication method (e.g., LDAP, GSSAPI) that depends on an external service with intermittent availability, this could explain the pattern.

5. HA proxy/VIP issues: Since this is described as a "high available fashion" setup, there may be a virtual IP, HAProxy, Patroni, or similar component that Tomas Vondra correctly identified as a potential culprit.

What Was NOT Provided

• Actual log excerpts (attachments were referenced but not included in the mailing list text)
• Network topology details
• Whether a connection pooler (PgBouncer, etc.) is in the path
• PostgreSQL configuration (postgresql.conf relevant settings)
• pg_hba.conf configuration
• OS-level network settings

Assessment of Thread

This is not a PostgreSQL internals or development issue. The pgsql-hackers list is for PostgreSQL source code development. This question belongs on:

• pgsql-general (the general usage mailing list)
• ServerFault or similar operational forums
• The user's organization's infrastructure/networking team

Tomas Vondra provided the correct guidance: systematically trace the connection path to identify where the failure occurs. No PostgreSQL code changes are implicated.

Outcome

The thread effectively died without resolution on the mailing list. Roberto Mello appears to have responded (possibly redirecting or noting the off-topic nature), but the content of his reply is not visible in the archive. The original poster continued to ask for fixes without providing the diagnostic information requested.