Comment vérifier les opérations en attente dans une transaction PostgreSQL ?

Question

J'ai une session (SQLAlchemy) sur PostgreSQL, avec une transaction active non validée. Je viens de passer la session à un arbre d'appel qui peut ou non avoir émis du SQL INSERT / UPDATE / DELETE les déclarations, par sqlalchemy.orm ou directement par la connexion sous-jacente.

Existe-t-il un moyen de vérifier s'il existe des instructions de modification de données en attente dans cette transaction ? C'est-à-dire si le commit est un no-op ou non, et si le rollback élimine quelque chose ou non ?

J'ai vu des gens faire remarquer v$transaction dans Oracle pour la même chose (voir cette question SO ). Je cherche quelque chose de similaire à utiliser sur PostgreSQL.

Answer 1

Commencez par vérifier dans la vue système pg_locks.

http://www.postgresql.org/docs/8.4/interactive/view-pg-locks.html

Answer 2

Considérez la séquence d'affirmations suivante :

select txid_current();

begin;

select txid_current();

Si l'identifiant de transaction renvoyé par les deux selects est égal, alors il y a une transaction ouverte. Sinon, il n'y en avait pas (mais il y en a une maintenant).

Si les chiffres sont différents, vous aurez simplement ouvert une transaction, que vous voudrez probablement clôturer.

UPDATE : En fait, comme le souligne @r2evans (merci pour la perspicacité !), vous n'avez pas besoin du "begin" -- txid_current() renverra le même nombre juste si vous êtes dans une transaction.

Answer 3

Depuis Postgres 10 :

select txid_current_if_assigned();

retournera null s'il n'y a pas de transaction en cours.

Si une transaction de démarrage a été émise, elle retournera toujours null s'il n'y a pas eu de mise à jour.

Answer 4

Non, pas au niveau de la base de données, vraiment. Peut-être pouvez-vous ajouter un traçage au niveau de sqlalchemy pour le suivre ?

Aussi, comment définissez-vous un no-op ? Si vous mettez à jour une valeur pour lui redonner la même valeur qu'avant, est-ce que c'est un no-op ou pas ? Du point de vue des bases de données, s'il y en avait un, ce ne serait pas un no-op. Mais du point de vue de l'application, ce serait probablement le cas.