pgaudit object coverage starts with the audit role's grants

pgAudit can add session and object-level audit records to PostgreSQL's standard logging. A configuration that sets a broad log class can look complete while object auditing remains empty. The extension needs the right server setup, and its object records depend on the audit role's grants.

Check the startup path

pgAudit must be loaded through shared_preload_libraries. Confirm that the library is present in the running server; a package on disk does not change the active process. A restart is required for a change to that setting, so a deployment that edits the configuration without restarting the process can leave the extension inactive.

Then inspect pgaudit.log. Session logging can cover read, write, function, role and DDL classes. Decide which classes are required, which databases need them and how the volume fits the logging pipeline. Enabling every class on a busy cluster can create a storage problem that quietly shortens the evidence available during an investigation.

Make object audit explicit

Object auditing uses pgaudit.role. The role is an audit identity, not a substitute for the application's permissions. Grant it access to the tables or columns whose operations must be recorded. A table that was never granted to the audit role will not appear simply because pgaudit.log is set to a high level.

Review grants after schema changes. A new table created by an application owner may not inherit the expected audit coverage. Include the audit role in the migration checklist and test the exact statement classes the application uses.

Separate the database audit log from the system log collector and from the long-term evidence store. Define who can read, alter or delete each copy. Capture the timestamp, database, user, statement class and normalized statement fields needed for correlation, while keeping parameters and sensitive literals out of unrestricted logs where possible.

Prove coverage with test statements

Run a permitted read, a denied read, an update through a function and a schema change. Confirm which events produced records and which were filtered by the log class or missing grant. Then repeat after a failover and after a restart.

The evidence should show that every required database and object is covered, that records arrive promptly and that retention survives normal deployment. A successful extension install is not enough.

References

• pgAudit README
• PostgreSQL: Logging Configuration