Issues Reference

Multiple indexes exist on the same table covering the same columns. Duplicate indexes waste storage and slow down writes without providing additional query benefits.

A table uses an integer (4-byte) primary key that may exhaust available IDs. For high-volume tables, this can cause application failures when IDs run out.

An index that failed to build completely and is marked as invalid. Invalid indexes are not used by queries but still consume resources.

A foreign key constraint exists without an index on the referencing columns. This causes full table scans when deleting or updating parent rows.

An index that has never been scanned since statistics were last reset. Unused indexes waste disk space and slow down write operations.

A table has autovacuum explicitly disabled, meaning it will not be automatically vacuumed by PostgreSQL.

A table's frozen transaction ID age is approaching the autovacuum_freeze_max_age threshold, which will trigger aggressive anti-wraparound vacuum.

A table has a high ratio of sequential scans to index scans, indicating that queries may be missing useful indexes.

A table has a high ratio of dead tuples to live tuples, indicating significant bloat. This wastes disk space and slows down sequential scans.

A table has accumulated dead tuples or hasn't been vacuumed recently, indicating maintenance is needed.

A table is created as UNLOGGED, meaning data is not written to WAL and will be lost on crash or unclean shutdown.

A sequence is approaching its maximum value and will soon be unable to generate new values, causing application failures.

The database is approaching transaction ID wraparound, which would force PostgreSQL to shut down to prevent data corruption.

A replication slot has significant lag, meaning the replica is far behind the primary database.

A replication slot is inactive (no consumer connected), causing WAL files to accumulate and potentially filling the disk.

A replication slot has an old xmin value, preventing VACUUM from removing dead tuples and causing table bloat.

A replication slot has a concerning WAL status, indicating WAL segments may be at risk of removal or already lost.

A query is blocked waiting for a lock held by another session. This creates a blocking chain that can cascade to affect multiple queries.

The database is approaching its max_connections limit. New connections may fail if the limit is reached.

A connection has been idle for an extended period, consuming a connection slot without doing useful work.

A connection is in "idle in transaction" state, holding locks and preventing VACUUM from cleaning up dead tuples.

A query has been executing for more than 5 minutes, which may indicate a performance problem or runaway operation.

A transaction has been open for more than 5 minutes, which may indicate a problem and can prevent vacuum from cleaning up dead tuples.

Autovacuum is disabled globally, which will cause table bloat, stale statistics, and eventual XID wraparound database shutdown.

Debug-level logging is enabled, creating massive log volumes and significant performance overhead.

Every SQL statement is being logged, creating massive log files and significant I/O overhead.

Very few connections are reserved for superusers, which may prevent administrators from connecting during a connection exhaustion crisis.

The autovacuum_freeze_max_age is set higher than recommended, delaying XID freezing and increasing wraparound risk.

Index scans are disabled, forcing all queries to use sequential scans regardless of available indexes.

Index-only scans are disabled, preventing PostgreSQL from using its most efficient scan method for covered queries.

Every query's duration is being logged (log_min_duration_statement = 0), creating excessive log output.

The checkpoint_completion_target is low, causing I/O spikes during checkpoints instead of smooth background writes.

No idle_in_transaction_session_timeout is set, meaning idle transactions can block vacuum and hold locks indefinitely.

No lock_timeout is configured, meaning queries can wait indefinitely for locks instead of failing fast.

No statement_timeout is configured, meaning queries can run indefinitely without being automatically terminated.

Statistics tracking (track_counts) is disabled, which breaks autovacuum and prevents collecting table and index statistics.

Synchronous commit is disabled, meaning committed transactions may be lost in a crash window of up to 600ms.

WAL level is set to minimal, which disables replication and prevents point-in-time recovery.

The database is using MD5 for password hashing, which is cryptographically broken and vulnerable to attacks.

The fsync setting is disabled, meaning PostgreSQL does not ensure data is written to disk. A crash will likely cause unrecoverable data corruption.

The full_page_writes setting is disabled, risking torn page corruption after a crash that cannot be detected or repaired.

An installed PostgreSQL extension has a newer version available that should be applied for security and feature improvements.