PREPARE TRANSACTION — prépare la transaction en cours pour une validation en deux phases
PREPARE TRANSACTION id_transaction
PREPARE TRANSACTION prépare la transaction courante en vue d'une validation en deux phases. À la suite de cette commande, la transaction n'est plus associée à la session courante ; au lieu de cela, son état est entièrement stocké sur disque. La probabilité est donc forte qu'elle puisse être validée avec succès, y compris en cas d'arrêt brutal de la base de données avant la demande de validation.
Une fois préparée, une transaction peut être validée ou annulée ultérieurement par, respectivement, COMMIT PREPARED et ROLLBACK PREPARED. Ces commandes peuvent être exécutées à partir d'une session quelconque. Il n'est pas nécessaire de le faire depuis celle qui a exécuté la transaction initiale.
Du point de vue de la session l'initiant, PREPARE TRANSACTION diffère peu de la commande ROLLBACK : après son exécution, il n'y a plus de transaction active et les effets de la transaction préparée ne sont plus visibles. (Les effets redeviendront visibles si la transaction est validée.)
Si la commande PREPARE TRANSACTION échoue, quelqu'en soit la raison, elle devient une commande ROLLBACK : la transaction courante est annulée.
Un identifiant arbitraire de la transaction pour les commandes COMMIT PREPARED et ROLLBACK PREPARED. L'identifiant, obligatoirement de type chaîne littérale, doit être d'une longueur inférieure à 200 octets. Il ne peut être identique à un autre identifiant de transaction préparée.
Cette commande doit être utilisée dans un bloc de transaction, initié par BEGIN.
Il n'est actuellement pas possible de préparer (PREPARE) une transaction qui a exécuté des opérations impliquant des tables temporaires ou qui a créé des curseurs WITH HOLD, ou qui a exécuté LISTEN ou UNLISTEN. Ces fonctionnalités sont trop intégrées à la session en cours pour avoir la moindre utilité dans une transaction préparée.
Si la transaction a modifié des paramètres en exécution à l'aide de la commande SET (sans l'option LOCAL), ces effets persistent au-delà du PREPARE TRANSACTION et ne seront pas affectés par les commandes COMMIT PREPARED et ROLLBACK PREPARED. Du coup, dans ce cas, PREPARE TRANSACTION agit plus comme COMMIT que comme ROLLBACK.
Toutes les transactions préparées disponibles sont listées dans la vue système pg_prepared_xacts.
Il est préférable de ne pas conserver trop longtemps des transactions préparées dans cet état ; cela compromet, par exemple, les possibilités de récupération de l'espace par VACUUM, et dans certains cas extrêmes peut causer l'arrêt de la base de données pour empêcher une réutilisation d'identifiants de transactions (voir Section 23.1.4, « Éviter les cycles des identifiants de transactions »). Il ne faut pas oublier non plus qu'une telle transaction maintient les verrous qu'elle a posé. L'usage principal de cette fonctionnalité consiste à valider ou annuler une transaction préparée dès lors qu'un gestionnaire de transactions externe a pu s'assurer que les autres bases de données sont préparées à la validation.
Si vous n'avez pas configuré un gestionnaire de transactions externe pour gérer les transactions préparées et vous assurer qu'elles sont fermées rapidement, il est préférable de désactiver la fonctionnalité des transactions préparées en configurant max_prepared_transactions à zéro. Ceci empêchera toute création accidentelle de transactions préparées qui pourraient alors être oubliées, ce qui finira par causer des problèmes.