Which connector?:  Postgres SQL

Additional details:Fivetran's regular PostgreSQL connector is executing a SELECT aurora_version() call against EDB Postgres (non-Aurora) database instances. Since EDB Postgres does not implement the aurora_version() function, this call fails and generates a recurring ERROR: function aurora_version() does not exist entry in the PostgreSQL logs.

Background ASUMPTION :

• Prior to the introduction of a dedicated Aurora PostgreSQL connector, Fivetran likely used a generic version-check routine (including an Aurora-specific check) as part of its regular PostgreSQL connector logic to detect engine type/version.
• With the subsequent release of a dedicated Aurora PG connector, this Aurora version check appears to have been left in place within the standard PostgreSQL connector path, even when connecting to non-Aurora, non-AWS-managed PostgreSQL instances (in this case, EDB Postgres).
• This results in the connector unnecessarily attempting an Aurora-specific function call that fails every time, polluting logs with errors.

Impact

• The recurring error is being picked up by our internal alert/log monitoring systems (regardless of log file size), triggering false-positive alerts.
• In the past, similar recurring errors from Qlik caused transaction restrictions, which required an eRFC to resolve. We want to avoid repeating that experience during this Fivetran HVR production cutover.

Evidence from DBA's:

1. Log excerpt showing repeated STATEMENT: SELECT aurora_version() calls followed by ERROR: function aurora_version() does not exist on an EDB Postgres instance (v21edbsl12), recurring across multiple dates (Nov 3, Nov 9, Nov 

• Update the standard PostgreSQL connector logic so that the Aurora version check (SELECT aurora_version()) is only executed when connecting to actual AWS Aurora PostgreSQL instances, OR
• Route Aurora-specific checks exclusively through the dedicated Aurora PostgreSQL connector, and remove/skip this check entirely for standard/EDB PostgreSQL connections.

Currently Databases under montitoring and this false error resulting  many internal incidents ...