Comment interpréter la valeur PosgreSQL txid_current()

Points clés à comprendre :

• Tout est dans une transaction. Si vous n'en créez pas explicitement un avec BEGIN et COMMIT (ou ROLLBACK ) un est créé pour vous juste pour cette déclaration.

• SELECT en lecture seule s n'obtiennent pas un ID de transaction complet, ils obtiennent uniquement un ID de transaction virtuelle. Ainsi, même s'il s'agit d'une transaction, SELECT 1; ou tout ce qui n'incrémente pas le compteur d'ID de transaction.

• Appel de txid_current() force l'attribution d'un ID de transaction s'il n'y en avait pas déjà un. Ainsi, une transaction en lecture seule aura désormais un ID de transaction, ce qui n'était pas le cas auparavant.

Bien sûr, les txids sont également alloués entre les sessions. En pratique, votre exemple ci-dessus peut obtenir des txid de a+1 et a+429 si la base de données est occupée.

Il n'est généralement pas judicieux d'utiliser l'ID de transaction pour quoi que ce soit au niveau de l'application. En particulier :

Traiter xmin et xmax comme des champs internes au niveau du système et traitez le résultat de txid_current() comme une valeur numérique sans signification.

Détails sur les utilisations correctes et incorrectes des xids

En particulier, vous ne devez jamais :

• Comparez les xids par valeur numérique pour tirer une quelconque conclusion sur leur ordre ;
• Ajouter ou soustraire des ID de transaction ;
• Trier les ID de transaction ;
• Incrémenter ou décrémenter les ID de transaction
• Comparer un xid 32 bits champ typé avec un bigint 64 bits xid étendu à l'époque, même pour l'égalité.

Ainsi, du point de vue de l'application, les xid ne sont ni monotones ni ordinaux.

Vous pouvez en toute sécurité :

• comparer deux xids étendus à l'époque 64 bits pour l'égalité ou l'inégalité ; et
• transmettre xids à txid_status(...) et d'autres fonctions documentées comme prenant un xid

Attention :PostgreSQL utilise des xid étroits de 32 bits comme le xid type et les xid étendus à l'époque 64 bits généralement représentés par bigint comme ceux renvoyés par txid_current() . La comparaison de ceux-ci pour l'égalité semblera généralement fonctionner sur une nouvelle installation de base de données, mais une fois que le premier bouclage d'époque s'est produit, ils ne seront plus égaux. Pg ne vous donne même pas un moyen simple de voir l'époque xid au niveau SQL ; vous devez :

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

pour obtenir les 32 bits supérieurs du xid étendu à l'époque rapporté par txid_current() .

Alors ... quoi que vous essayiez de faire, il est probable que l'ID de transaction ne soit pas la bonne façon de le faire.