Postgres 9,5 ha introdotto una nuova funzionalità correlata a questo problema:commit timestamp .
Devi solo attivare track_commit_timestamp
in postgresql.conf (e riavvia!) per iniziare a tenere traccia dei timestamp di commit. Quindi puoi interrogare:
SELECT * FROM tbl
WHERE pg_xact_commit_timestamp(xmin) >= '2015-11-26 18:00:00+01';
Leggi il capitolo "Commit timestamp tracking"
nel Wiki di Postgres.
Utility utility funzioni nel manuale
.
La volatilità della funzione è solo VOLATILE perché gli ID transazione (xid ) può avvolgere per definizione. Quindi non puoi creare un indice funzionale su di esso.
Potresti falsificare IMMUTABLE volatilità in un wrapper di funzioni per applicazioni in un intervallo di tempo limitato, ma è necessario essere consapevoli delle implicazioni. Caso correlato con ulteriori spiegazioni:
- PostgreSQL supporta "accent insensitive " regole di confronto?
- In che modo le parole chiave IMMUTABLE, STABLE e VOLATILE influiscono sul comportamento della funzione?
Per molti casi d'uso (come il tuo?) che sono interessati solo alla sequenza dei commit (e non al tempo assoluto) potrebbe essere più efficiente lavorare con xmin trasmettere a bigint "direttamente" (xmin::text::bigint ) invece dei timestamp del commit. (xid è un intero senza segno internamente, la metà superiore che non rientra in un integer con segno .) Ancora una volta, tieni presente le limitazioni dovute al possibile avvolgimento di xid.
Per lo stesso motivo, i timestamp di commit non vengono conservati a tempo indeterminato . Per database di piccole e medie dimensioni, xid l'avvolgimento non si verifica quasi mai, ma alla fine succederà se il cluster è attivo abbastanza a lungo. Leggi il capitolo "Prevenzione degli errori di wrapping dell'ID transazione" nel manuale per i dettagli.
