PostgreSQL Prepared Statement Collision with ProxySQL 3.0.8

Summary

We are experiencing intermittent PostgreSQL errors involving prepared statements after migrating a production application from PgBouncer to ProxySQL 3.0.8.

ProxySQL 3.0.11 is now available, but we have not yet deployed it to our production environment, so we cannot confirm whether this issue is still present or has been resolved in that version.

We are submitting this report to document the issue, determine whether it is a known problem, and verify whether a fix or relevant change has been included in a newer ProxySQL release.

The application reports:

42P05: prepared statement "proxysql_ps_1" already exists

We did not observe this issue while using PgBouncer with the same application and PostgreSQL environment. The issue appeared after introducing ProxySQL.

Our primary suspicion is that the issue may be related to ProxySQL's backend connection handling or query routing during periods of PostgreSQL replica replication lag. However, we have not yet confirmed that replication lag is the direct trigger.

We would appreciate help determining whether this behavior is expected, a known issue, or a bug in ProxySQL's PostgreSQL prepared-statement handling.

Environment

• ProxySQL version: 3.0.8
• Database: PostgreSQL
• Previous connection pooler: PgBouncer
• Previous pooler behavior: No observed occurrence of this error
• Current pooler: ProxySQL 17
• Environment: Production
• Application: .NET-based EF application using PostgreSQL.
• Database topology: PostgreSQL primary with read replicas
• Query routing: ProxySQL routes database traffic between primary and replicas (%99 of read queries are routed to the replicas and %1 to the primary. When there is a lag more than a certain threshold, read queries all routed to the primary)
• Application workload: API requests using parameterized queries / prepared statements

Observed Error

The application receives an HTTP 500 response when executing a database query.

An anonymized example is shown below:

{
  "executionError": [
    {
      "$id": "13",
      "ErrorTime": "2026-08-10T11:41:06.5900053Z",
      "StepName": "API Get Part Info",
      "StepId": "<REDACTED_STEP_ID>",
      "StepNo": 18,
      "RetryCount": 1,
      "Message": "{\"code\":\"ErrorsOccuredInQueryActionOfProductController\",\"message\":\"Errors occured in 'Query' action of 'Product' controller\",\"details\":[{\"code\":\"InternalServerError\",\"message\":\"42P05: prepared statement \\\"proxysql_ps_1\\\" already exists\"}]}",
      "StepType": "ApiCallerStep",
      "InnerException": null,
      "ErrorType": "InternalServerError",
      "ErrorDetails": {
        "$id": "14",
        "EndpointUrl": "http://<REDACTED_INTERNAL_SERVICE>/<REDACTED_ENDPOINT>",
        "EndpointMethod": "POST",
        "EndpointErrorCode": "500"
      },
      "CEHDetails": {
        "$id": "15",
        "ErrorCategory": "NonTransientServerIssue",
        "ErrorCategoryCode": "<REDACTED_ERROR_CODE>",
        "StatusCode": 500,
        "Message": "Service Unavailable Non Transient error",
        "Details": {
          "$id": "16",
          "$values": [
            "Response status code does not indicate success: 500 (Internal Server Error)."
          ]
        },
        "CorrelationId": "<REDACTED_CORRELATION_ID>",
        "Category": 5,
        "ErrorCode": 1999,
        "Timestamp": "2026-08-10T11:41:06.5779799Z",
        "Context": {
          "$id": "17"
        },
        "ShouldRetry": false,
        "NotifyUser": true
      }
    }
  ]
}

The essential database error is:

SQLSTATE: 42P05
prepared statement "proxysql_ps_1" already exists

What Changed

The main relevant infrastructure change was replacing PgBouncer with ProxySQL 3.0.8.

The application and PostgreSQL environment were otherwise substantially the same.

After the migration, we began observing intermittent prepared-statement errors in production.

Suspected Trigger

Our current hypothesis is that the issue may occur during periods of replication lag on PostgreSQL replicas.

The suspected sequence is:

1. The application sends a query through ProxySQL.

2. ProxySQL routes the query according to its PostgreSQL hostgroup/routing configuration.

3. Replication lag occurs on one or more replicas.

4. ProxySQL detects the replica state or changes its routing behavior, potentially routing subsequent queries to the primary.

5. A prepared statement with a name such as proxysql_ps_1 is created or reused on a backend connection.

6. PostgreSQL returns:

   复制

   42P05: prepared statement "proxysql_ps_1" already exists

We would particularly like to understand whether ProxySQL can cause a prepared statement to be sent to a backend session where that statement name already exists, or whether a connection/session transition can produce this condition.

Expected Behavior

Prepared statements should be handled consistently across client and backend sessions, without causing intermittent 42P05 errors during normal connection reuse or backend routing changes.

If a backend connection is reused, the prepared-statement state should remain consistent with the behavior expected by the PostgreSQL client driver.

Actual Behavior

Intermittent requests fail with HTTP 500 because PostgreSQL reports that a prepared statement name already exists.

The issue was not observed with PgBouncer but appeared after switching to ProxySQL 3.0.8.