Hi On Wed, 5 Aug 2026 at 13:30, abhishek s <[email protected]> wrote:
> Hi Dave, > > What is the option then to know which user does any change in production > wth pgadmin using admin credentials? > Enable the required logging on the server: https://www.postgresql.org/docs/current/runtime-config-logging.html. Typically you'd probably want to set the log_line_prefix to contain whatever info you want, and then use options such as log_statements to enable logging of the actions that interest you. > > On Wed, 5 Aug, 2026, 2:52 pm Dave Page, <[email protected]> wrote: > >> Hi >> >> On Wed, 5 Aug 2026 at 10:13, abhishek s <[email protected]> wrote: >> >>> Hi team, >>> >>> Background >>> The current PostgreSQL audit logs in Azure record are below >>> >>> Database user >>> >>> Database name >>> >>> Client IP (appears as the Zscaler egress IP) >>> >>> Application name (currently pgAdmin4) >>> >>> Problem >>> Because the organization uses VPN or a similar proxy, PostgreSQL only >>> sees the proxy's IP address instead of the actual user's workstation IP. >>> >>> As a result: >>> >>> The Client IP is not useful for identifying who accessed the database. >>> >>> The application_name is always "pgAdmin4", which is static. >>> >>> Security and audit teams cannot determine: >>> >>> Which workstation connected >>> >>> Which employee initiated the connection >>> >>> Which machine executed the SQL statements >>> >>> Proposed Enhancement: >>> The request suggests that pgAdmin should automatically populate >>> PostgreSQL's application_name connection parameter with client metadata >>> when establishing the database connection. >>> >> >> You absolutely should NOT use application_name for security or audit >> purposes. It's a client-side parameter that a user can override in any way >> they like. Its purpose is to provide convenience when monitoring the server >> by identifying what a connection is being used for. That's fine for day to >> day monitoring with well behaved users, but you cannot rely on it for >> audit/security purposes as an attacker can simply override it. >> >> -- >> Dave Page >> pgAdmin: https://www.pgadmin.org >> PostgreSQL: https://www.postgresql.org >> pgEdge: https://www.pgedge.com >> >> -- Dave Page pgAdmin: https://www.pgadmin.org PostgreSQL: https://www.postgresql.org pgEdge: https://www.pgedge.com
