Analyse des requêtes et transactions en cours

On va commencer par la base. PostgreSQL te file un super set d'outils pour analyser les requêtes SQL et les transactions. Par exemple, les fonctions intégrées current_query() et txid_current() te permettent de :

• Récupérer la requête SQL en cours d'exécution.
• Savoir dans quelle transaction la requête tourne.
• Logger les opérations SQL pour les analyser plus tard.
• Suivre les soucis de transactions, genre quand ton code attend un truc mais il se passe tout autre chose.

Tout ça peut vraiment te sauver la mise quand le debug classique ne suffit pas ou si tu veux analyser le comportement des requêtes "après coup".

Vue d'ensemble des fonctions intégrées

Fonction current_query()

current_query() te renvoie le texte de la requête SQL en cours d'exécution sur la connexion. "Mais comment il sait ça ?" — tu vas me demander. PostgreSQL garde un œil sur l'état de chaque connexion, et cette fonction te permet de jeter un œil dans les coulisses.

Syntaxe :

SELECT current_query();

Exemple d'exécution :

-- On exécute une requête dans une fonction
DO $$
BEGIN
    RAISE NOTICE 'Requête en cours : %', current_query();
END;
$$;

-- Résultat :
-- NOTICE: Requête en cours : DO $$ BEGIN RAISE NOTICE 'Requête en cours : %', current_query(); END; $$;

Comme tu le vois dans l'exemple, current_query() te donne le texte de la requête en cours. C'est super utile pour analyser des procédures complexes : tu sais exactement ce qui s'exécute à l'instant T !

Fonction txid_current()

Quand tu bosses avec les transactions, la fonction txid_current() est juste géniale. Elle te renvoie un identifiant unique pour la transaction en cours. C'est super pratique si tu veux suivre la séquence d'opérations dans une même transaction.

Syntaxe :

SELECT txid_current();

Exemple d'exécution :

BEGIN;

-- Récupérer l'ID de la transaction en cours
SELECT txid_current();

-- Affichage :
-- 564 (par exemple, l'identifiant)

-- On termine la transaction
COMMIT;

Ces IDs de transaction peuvent servir à faire le lien entre les logs, analyser la séquence des actions et même débugger des systèmes multi-utilisateurs.

Exemples d'utilisation dans des cas réels

1. Logger la requête en cours pendant l'exécution.

Parfois, une procédure ou une fonction contient plein de requêtes SQL. Pour piger où ça coince, tu peux activer le logging de la requête SQL en cours. Par exemple :

DO $$
DECLARE
    current_txn_id BIGINT;
BEGIN
    current_txn_id := txid_current();
    RAISE NOTICE 'ID de la transaction en cours : %', current_txn_id;

    RAISE NOTICE 'Requête en cours : %', current_query();

    -- Ici tu pourrais avoir d'autres opérations
END;
$$;

Ce code va afficher dans la console l'identifiant de la transaction et le texte de la requête en cours. Comme ça, tu sais exactement ce qui tourne à ce moment-là.

2. Analyser les transactions pour trouver les problèmes.

Imagine un scénario où les utilisateurs râlent parce qu'ils perdent des données lors d'une grosse mise à jour. Tu crées plusieurs procédures, chacune lancée dans une seule transaction. Comment savoir qui est responsable ? Voilà un exemple :

BEGIN;

-- On ajoute du logging sur la transaction
DO $$
BEGIN
    RAISE NOTICE 'ID de la transaction en cours : %', txid_current();
END;
$$;

-- On exécute la requête SQL "problématique"
UPDATE orders
SET status = 'processed'
WHERE id IN (SELECT order_id FROM pending_orders);

COMMIT;

Si les updates ne passent pas, tu vois direct l'ID de la transaction concernée par tes modifs. Ça simplifie grave la recherche d'erreur et ça aide à voir s'il y a eu des conflits de transactions.

3. Logger les requêtes pour une analyse historique.

Parfois, tu veux pas juste corriger le bug du moment, mais aussi garder une trace des requêtes SQL exécutées. Par exemple, tu peux créer une table de log :

CREATE TABLE query_log (
    log_time TIMESTAMP DEFAULT NOW(),
    query_text TEXT,
    txn_id BIGINT
);

Voilà comment tu peux enregistrer les requêtes avec current_query() et txid_current() :

DO $$
BEGIN
    INSERT INTO query_log (query_text, txn_id)
    VALUES (current_query(), txid_current());
END;
$$;

Maintenant, dans la table query_log, t'as l'info sur chaque requête exécutée et la transaction associée. C'est un outil en or pour analyser le fonctionnement de ta base.

Cas pratiques d'utilisation

Exemple 1 : audit des transactions

Imagine que tu analyses les opérations dans un système multi-utilisateurs. Logger l'ID de transaction (txid_current) te permet de regrouper les actions par transaction.

DO $$
DECLARE
    txn_id BIGINT;
BEGIN
    txn_id := txid_current();
    RAISE NOTICE 'Transaction démarrée avec l’ID : %', txn_id;

    -- Une opération quelconque
    UPDATE users SET last_login = NOW() WHERE id = 123;

    RAISE NOTICE 'Requête en cours : %', current_query();
END;
$$;

Exemple 2 : faciliter le debug des procédures

Tu lances une procédure complexe et ça part en vrille. Tu peux intégrer le logging current_query() à différents moments de la fonction pour voir quelle requête s'exécutait :

CREATE OR REPLACE FUNCTION debugged_function() RETURNS VOID AS $$
BEGIN
    RAISE NOTICE 'Requête avant update : %', current_query();
    UPDATE data_table SET field = 'debugging';
    RAISE NOTICE 'Requête après update : %', current_query();
END;
$$ LANGUAGE plpgsql;

Quand tu appelles la fonction, tu reçois deux notifications avec les requêtes SQL correspondantes.

Astuces d'utilisation

1. Utilise current_query() pour logger les requêtes dans les systèmes multi-utilisateurs, histoire de piger quelles actions sont faites.
2. txid_current() est parfait pour analyser l'origine des changements : à quel moment de ta transaction les données ont été ajoutées ou modifiées.
3. N'oublie pas de virer le logging inutile quand t'as fini. Les notifications permanentes via RAISE NOTICE peuvent ralentir tes fonctions.

Ces fonctions intégrées, c'est un peu ton "microscope" pour explorer les moindres détails de ta base de données. Elles t'aident à choper les bugs, booster les perfs et comprendre ce qui se passe dans les systèmes complexes. Quelque part, au fond de PostgreSQL, ta base est déjà prête à te filer ses secrets — il te reste juste à apprendre à les lire.