Outre ses colonnes régulières, les tables Postgres ont également différentes colonnes système disponibles. L'un d'eux, xmin
stocke l'ID de transaction utilisé pour créer une ligne. Son type de données est xid
un entier de quatre octets qui se termine à un moment donné (c'est-à-dire pas nécessairement unique). La fonction txid_current()
retourne à son tour l'ID de transaction actuel, mais comme bigint
, car il "est étendu avec un compteur" epoch "afin qu'il ne se termine pas pendant la durée de vie d'une installation" (pour citer le manuel ).
Si le bouclage des transactions ne s'est pas encore produit, les deux valeurs semblent correspondre:
# CREATE TABLE test (label text);
CREATE TABLE
# INSERT INTO test VALUES ('test') RETURNING txid_current();
txid_current
--------------
674500
(1 row)
INSERT 0 1
# SELECT xmin FROM test;
xmin
--------
674500
(1 row)
Mais je me demande: ces deux valeurs sont-elles toujours comparables? Pour autant que je sache, txid_current()
continuera à fournir des valeurs uniques après le bouclage de l'ID de transaction (au plus 2 ^ 32 transactions) et xmin
commencera à zéro. Cela signifie que les deux commencent à renvoyer des valeurs différentes à ce point?
Et si cela est vrai, existe-t-il un moyen d'extraire régulièrement xid
un txid_current()
résultat afin qu'il corresponde aux xmin
entrées d'une table (par exemple, un cast txid_current()
en entier)?
Edit : clarifiez que je me soucie de ce qui se passe après un bouclage d'ID de transaction, ce qui se produit très probablement bien avant 2 ^ 32 transactions. Merci à Daniel Vérité de l'avoir noté dans les commentaires.
xmin
gelé, la question reste de savoir comment les nouveaux (réguliers) se xmin
comparent à ceux qui sont exécutés txid_current()
.
VACUUM FREEZE
écrasera et remplacera lesxmin
lignes bien avant le bouclage 2 ^ 32. Consultez Freezing Your Tuples Off pour un aperçu du sujet.