Postgres 9,5 heeft een nieuwe functie geïntroduceerd die verband houdt met dit probleem:tijdstempels vastleggen .
Je hoeft alleen maar track_commit_timestamp
in postgresql.conf (en herstart!) om commit-tijdstempels bij te houden. Dan kunt u vragen:
SELECT * FROM tbl
WHERE pg_xact_commit_timestamp(xmin) >= '2015-11-26 18:00:00+01';
Lees het hoofdstuk "Timestamp tracking vastleggen"
in de Postgres Wiki.
Verwante hulpprogramma functies in de handleiding
.
Functievolatiliteit is alleen VLUCHTIG omdat transactie-ID's (xid ) kan per definitie omwikkelen. U kunt dus geen functionele index maken erop.
Je zou IMMUTABLE . kunnen faken volatiliteit in een functie-wrapper voor toepassingen in een beperkt tijdsbestek, maar u moet zich bewust zijn van de implicaties. Gerelateerde casus met meer uitleg:
- Ondersteunt PostgreSQL "accent ongevoelig " collaties?
- Hoe beïnvloeden IMMUTABLE, STABLE en VOLATILE zoekwoorden het gedrag van de functie?
Voor veel gevallen (zoals die van jou?) die alleen geïnteresseerd zijn in de volgorde van commits (en niet in absolute tijd), kan het efficiënter zijn om met xmin te werken. casten naar bigint "direct" (xmin::text::bigint ) in plaats van commit-tijdstempels. (xid is intern een niet-ondertekend geheel getal, de bovenste helft past niet in een ondertekend geheel getal .) Nogmaals, houd rekening met beperkingen als gevolg van mogelijke xid-omhulling.
Om dezelfde reden worden commit-tijdstempels niet voor onbepaalde tijd bewaard . Voor kleine tot middelgrote databases, xid wraparound gebeurt bijna nooit - maar uiteindelijk zal het gebeuren als het cluster lang genoeg live is. Lees het hoofdstuk "Omwikkelingsfouten met transactie-ID's voorkomen" in de handleiding voor details.