PREPARE TRANSACTION — prepara la transacción actual para una confirmación en dos fases (two-phase commit)
PREPARE TRANSACTION transaction_id
PREPARE TRANSACTION prepara la transacción actual
para una confirmación en dos fases. Después de este comando, la transacción ya no está
asociada con la sesión actual; en su lugar, su estado se almacena completamente en el
disco, y hay una probabilidad muy alta de que se pueda confirmar
con éxito, incluso si ocurre una caída de la base de datos antes de que se solicite la confirmación.
Una vez preparada, una transacción puede confirmarse o revertirse más tarde
con COMMIT PREPARED
o ROLLBACK PREPARED,
respectivamente. Estos comandos pueden emitirse desde cualquier sesión, no
solo desde la que ejecutó la transacción original.
Desde el punto de vista de la sesión emisora, PREPARE
TRANSACTION no es muy diferente a un comando ROLLBACK:
después de ejecutarlo, no hay ninguna transacción activa actual, y los
efectos de la transacción preparada ya no son visibles. (Los efectos
volverán a ser visibles si la transacción se confirma).
Si el comando PREPARE TRANSACTION falla por cualquier
razón, se convierte en un ROLLBACK: la transacción actual
se cancela.
transaction_id
Un identificador arbitrario que luego identifica esta transacción para
COMMIT PREPARED o ROLLBACK PREPARED.
El identificador debe escribirse como una cadena literal y debe tener
menos de 200 bytes de longitud. No debe ser el mismo que el identificador
utilizado para cualquier transacción preparada actualmente.
PREPARE TRANSACTION no está pensado para su uso en aplicaciones
o sesiones interactivas. Su propósito es permitir que un gestor de transacciones
externo realice transacciones globales atómicas a través de múltiples
bases de datos u otros recursos transaccionales. A menos que estés escribiendo un
gestor de transacciones, probablemente no deberías usar PREPARE
TRANSACTION.
Este comando debe utilizarse dentro de un bloque de transacción. Utiliza BEGIN para iniciar uno.
Actualmente no está permitido preparar (PREPARE) una transacción que
haya ejecutado operaciones que involucren tablas temporales o el espacio de nombres
temporal de la sesión, que haya creado cursores WITH HOLD o que haya
ejecutado LISTEN, UNLISTEN o
NOTIFY.
Esas características están demasiado ligadas
a la sesión actual como para ser útiles en una transacción que se va a preparar.
Si la transacción modificó algún parámetro de tiempo de ejecución con SET
(sin la opción LOCAL),
esos efectos persisten después de PREPARE TRANSACTION y no
se verán afectados por ningún COMMIT PREPARED o
ROLLBACK PREPARED posterior. Por lo tanto, en este aspecto
PREPARE TRANSACTION actúa más como un COMMIT que como un
ROLLBACK.
Todas las transacciones preparadas disponibles actualmente se enumeran en la vista
de sistema pg_prepared_xacts.
No es prudente dejar las transacciones en estado preparado durante mucho tiempo.
Esto interferirá con la capacidad de VACUUM para reclamar
almacenamiento y, en casos extremos, podría provocar que la base de datos se detenga
para evitar la envoltura (wraparound) del ID de transacción (consulta Section 24.1.5). Ten en cuenta también que la transacción
continúa manteniendo los bloqueos que tuviera. El uso previsto de esta
característica es que una transacción preparada se confirme o se
revierta tan pronto como un gestor de transacciones externo haya verificado que
las otras bases de datos también están preparadas para confirmar.
Si no has configurado un gestor de transacciones externo para rastrear las transacciones preparadas y garantizar que se cierren de inmediato, es mejor mantener desactivada la función de transacciones preparadas estableciendo max_prepared_transactions en cero. Esto evitará la creación accidental de transacciones preparadas que luego podrían quedar en el olvido y eventualmente causar problemas.
Prepara la transacción actual para una confirmación en dos fases, utilizando
foobar como identificador de la transacción:
PREPARE TRANSACTION 'foobar';
PREPARE TRANSACTION es una extensión de
PostgreSQL. Está pensado para ser utilizado por
sistemas externos de gestión de transacciones, algunos de los cuales están cubiertos por
estándares (como X/Open XA), pero el aspecto SQL de esos sistemas no está
estandarizado.