Postgres 9.5 introduit une nouvelle fonctionnalité liée à ce problème :horodatages de validation .
Il vous suffit d'activer track_commit_timestamp
dans postgresql.conf (et redémarrez !) pour commencer à suivre les horodatages de validation. Ensuite, vous pouvez interroger :
SELECT * FROM tbl
WHERE pg_xact_commit_timestamp(xmin) >= '2015-11-26 18:00:00+01';
Lire le chapitre "Commit timestamp tracking"
dans le Wiki Postgres.
Utilitaire associé fonctions dans le manuel
.
La volatilité de la fonction est uniquement VOLATILE car les identifiants de transaction (xid ) peut s'enrouler par définition. Donc, vous ne pouvez pas créer un index fonctionnel dessus.
Vous pourriez falsifier IMMUTABLE volatilité dans un wrapper de fonction pour les applications dans un laps de temps limité, mais vous devez être conscient des implications. Cas connexe avec plus d'explications :
- Est-ce que PostgreSQL prend en charge "insensible aux accents " classements ?
- Comment les mots clés IMMUTABLE, STABLE et VOLATILE affectent-ils le comportement de la fonction ?
Pour de nombreux cas d'utilisation (comme le vôtre ?) qui ne s'intéressent qu'à la séquence des commits (et non au temps absolu), il peut être plus efficace de travailler avec xmin convertir en bigint "directement" (xmin::text::bigint ) au lieu des horodatages de validation. (xid est un entier non signé en interne, la moitié supérieure qui ne rentre pas dans un integer signé .) Encore une fois, soyez conscient des limitations dues à un éventuel bouclage xid.
Pour la même raison, les horodatages de validation ne sont pas conservés indéfiniment . Pour les petites et moyennes bases de données, xid le bouclage ne se produit presque jamais - mais il finira par arriver si le cluster est actif assez longtemps. Lisez le chapitre "Preventing Transaction ID Wraparound Failures" dans le manuel pour plus de détails.
