Postgres 9.5 introducerade en ny funktion relaterad till detta problem:commit timestamps .
Du behöver bara aktivera track_commit_timestamp
i postgresql.conf (och starta om!) för att börja spåra commit-tidsstämplar. Sedan kan du fråga:
SELECT * FROM tbl
WHERE pg_xact_commit_timestamp(xmin) >= '2015-11-26 18:00:00+01';
Läs kapitlet "Commit timestamp tracking"
i Postgres Wiki.
Relaterat verktyg funktioner i manualen
.
Funktionsvolatiliteten är bara VOLATILE eftersom transaktions-ID:n (xid ) kan svepa runt per definition. Så du kan inte skapa ett funktionellt index på den.
Du kan förfalska IMMUTABLE volatilitet i ett funktionsomslag för applikationer inom en begränsad tidsram, men du måste vara medveten om konsekvenserna. Relaterat fall med mer förklaring:
- Stöder PostgreSQL "accent insensitive" " sammanställningar?
- Hur påverkar IMUTABLE, STABLE och VOLATILA nyckelord funktionsbeteende?
För många användningsfall (som ditt?) som bara är intresserade av sekvensen av bekräftelser (och inte absolut tid) kan det vara mer effektivt att arbeta med xmin casta till bigint "direkt" (xmin::text::bigint ) istället för att bestämma tidsstämplar. (xid är ett internt osignerat heltal, den övre halvan som inte passar in i ett integer med tecken .) Återigen, var medveten om begränsningar på grund av eventuell xid-omslutning.
Av samma anledning bevaras tidsstämplar för commit inte på obestämd tid . För små till medelstora databaser, xid wraparound händer nästan aldrig - men det kommer så småningom om klustret är levande tillräckligt länge. Läs kapitlet "Förhindra transaktions-ID Wraparound-fel" i manualen för detaljer.