Postgres 9.5 hat eine neue Funktion in Bezug auf dieses Problem eingeführt:commit timestamps .
Sie müssen nur track_commit_timestamp
in postgresql.conf (und neu starten!), um mit der Nachverfolgung von Commit-Zeitstempeln zu beginnen. Dann können Sie abfragen:
SELECT * FROM tbl
WHERE pg_xact_commit_timestamp(xmin) >= '2015-11-26 18:00:00+01';
Lesen Sie das Kapitel "Commit-Timestamp-Tracking"
im Postgres-Wiki.
Zugehöriges Dienstprogramm Funktionen im Handbuch
.
Die Volatilität der Funktion ist nur VOLATILE weil Transaktions-IDs (xid ) kann per Definition umlaufen. Sie können also keinen funktionalen Index erstellen drauf.
Sie könnten IMMUTABLE fälschen Volatilität in einem Funktionswrapper für Anwendungen in einem begrenzten Zeitrahmen, aber Sie müssen sich der Auswirkungen bewusst sein. Verwandter Fall mit mehr Erklärung:
- Unterstützt PostgreSQL "accent insensitive " Sortierungen?
- Wie wirken sich die Schlüsselwörter IMMUTABLE, STABLE und VOLATILE auf das Verhalten der Funktion aus?
Für viele Anwendungsfälle (wie Ihren?), die nur an der Abfolge von Commits (und nicht an der absoluten Zeit) interessiert sind, könnte es effizienter sein, mit xmin zu arbeiten in bigint umwandeln "direkt" (xmin::text::bigint ) anstelle von Commit-Zeitstempeln. (xid ist intern eine Ganzzahl ohne Vorzeichen, die obere Hälfte passt nicht in eine vorzeichenbehaftete Ganzzahl .) Beachten Sie auch hier die Einschränkungen aufgrund eines möglichen xid-Wraparounds.
Aus dem gleichen Grund werden Commit-Zeitstempel nicht unbegrenzt aufbewahrt . Für kleine bis mittlere Datenbanken xid Wraparound passiert kaum - aber es wird irgendwann passieren, wenn der Cluster lange genug aktiv ist. Lesen Sie das Kapitel "Preventing Transaction ID Wraparound Failures" Einzelheiten finden Sie im Handbuch.
