Hoe PosgreSQL txid_current() waarde te interpreteren

Belangrijkste punten om te begrijpen:

• Alles zit in een transactie. Als u er niet expliciet een maakt met BEGIN en COMMIT (of ROLLBACK ) er is er een speciaal voor jou gemaakt voor die verklaring.

• Alleen-lezen SELECT s krijgen geen volledige transactie-ID, ze krijgen alleen een virtuele transactie-ID. Dus ook al is het een transactie, SELECT 1; of wat dan ook verhoogt de transactie-ID-teller niet.

• Aanroepen van txid_current() krachten de toewijzing van een transactie-ID als deze nog niet was toegewezen. Dus een alleen-lezen transactie heeft nu een transactie-ID, waar dit voorheen niet het geval was.

Natuurlijk worden txids ook verdeeld over sessies. In de praktijk kan uw voorbeeld hierboven txid's van a+1 en a+429 krijgen als de database bezet is.

Het is over het algemeen niet verstandig om de transactie-ID voor iets op applicatieniveau te gebruiken. In het bijzonder:

Behandel xmin en xmax als interne velden op systeemniveau, en behandel het resultaat van txid_current() als een betekenisloze numerieke waarde.

Details over correct en onjuist gebruik van xids

In het bijzonder mag u nooit:

• Vergelijk xids met numerieke waarde om enige conclusie te trekken over hun volgorde;
• Transactie-ID's toevoegen of aftrekken;
• Sorteer transactie-ID's;
• Transactie-ID's verhogen of verlagen
• Vergelijk een 32-bits xid getypt veld met een 64-bits bigint epoch-extended xid, zelfs voor gelijkheid.

Dus vanuit een toepassingsperspectief zijn xids noch monotoon noch ordinaal.

Je kunt veilig:

• vergelijk twee 64-bit epoch-extended xids voor gelijkheid of ongelijkheid; en
• geef xids door aan txid_status(...) en andere functies gedocumenteerd als het nemen van een xid

Pas op:PostgreSQL gebruikt 32-bits smalle xids zoals de xid type, en 64-bit epoch-extended xids meestal weergegeven als bigint zoals die geretourneerd door txid_current() . Het vergelijken van deze voor gelijkheid zal over het algemeen lijken te werken bij een nieuwe database-installatie, maar zodra de eerste epoch-omhulling heeft plaatsgevonden, zullen ze niet langer gelijk zijn. Pg geeft je niet eens een gemakkelijke manier om het xid-tijdperk op SQL-niveau te zien; je moet:

select (txid_current() >> 32) AS xid_epoch;

om de bovenste 32 bits van de epoch-extended xid te krijgen, gerapporteerd door txid_current() .

Dus ... wat u ook probeert te doen, het is waarschijnlijk dat de transactie-ID niet de juiste manier is om het te doen.