DBAtlas · Atlas für Datenbankbetrieb

xmin-Horizont-Halter finden, die VACUUM am Entfernen toter Tupel hindern

PostgreSQLWartung

Befehl

SELECT 'session' AS source, pid::text AS id, usename::text AS owner, state AS detail,
       age(backend_xmin) AS xmin_age
FROM pg_stat_activity
WHERE backend_xmin IS NOT NULL AND pid <> pg_backend_pid()
UNION ALL
SELECT 'prepared_xact', gid, owner::text, prepared::text, age(transaction)
FROM pg_prepared_xacts
UNION ALL
SELECT 'replication_slot', slot_name::text, slot_type, active::text,
       greatest(age(xmin), age(catalog_xmin))
FROM pg_replication_slots
WHERE xmin IS NOT NULL OR catalog_xmin IS NOT NULL
UNION ALL
SELECT 'standby_feedback', application_name, usename::text, state, age(backend_xmin)
FROM pg_stat_replication
WHERE backend_xmin IS NOT NULL
ORDER BY xmin_age DESC NULLS LAST;

Was es tut

Listet, sortiert nach xmin-Alter, die vier Quellen, die die Bereinigung toter Tupel blockieren können: Sessions mit Snapshots, Prepared Transactions, Replication Slots und Standbys, die hot_standby_feedback senden.

Wann einsetzen

Wenn VACUUM VERBOSE 'dead row versions cannot be removed yet' meldet, Bloat weiter wächst und das XID-Alter nicht sinkt.

Vorsicht

Das älteste xmin bestimmt den Bereinigungshorizont; Replication Slots und Standby-Feedback wirken auf alle Datenbanken. Prepared Transactions überstehen Neustarts; prüfe den Eigentümer und schließe sie mit COMMIT PREPARED / ROLLBACK PREPARED '<gid>'. Das Löschen eines ungenutzten Slots unterbricht seinen Downstream (Standby, CDC); prüfe zuerst den Eigentümer. Auf einem Standby ausgeführt, zeigt es nur die Sessions dieses Standby.

In DBAtlas öffnen →

Verwandte Einträge