Raul Duque escribió: > El número que aparece posterior a la IP es el transaction Id. Como > pueden observar las primeras sentencias se ejecutan aparentemente > fuera de una transacción aunque ya se había ejecutado el "BEGIN". > Incluso existe un SAVEPOINT que se ejecuta crea fuera de la > transacción y se hace release dentro de la transacción.
Ya entiendo lo que pasa. En 8.3 hay una optimización que permite que una transacción no adquiera un ID de transacción hasta que ese ID se necesita para algo, que es el UPDATE que se ve justo ahí donde cambia el ID en el log. > Aunque no copio todo el log para esta transacción porque es muy > extenso, no hay ningún error del motor reportado en el log entre el > BEGIN-COMMIT. Incluso el servidor no se reiniciado desde esa fecha. > > El resultado en la base de datos fue que solo una parte de las > sentencias que cubría la transacción quedaron en firme con las > complicaciones que trae una situación de estas. Alguna idea de qué > pudo haber pasado? No, creo que esto es otra cosa. De hecho me pregunto si tiene que ver con los SAVEPOINT que muestras: cada sentencia está rodeada de un savepoint/release. Si alguna sentencia fallara por cualquier motivo, podría haber un ROLLBACK TO ese savepoint, y entonces el resto de la transacción podría continuar sin problemas. Tienes que investigar de dónde vienen esos savepoints. Quizás se cambió una opción del driver ODBC, y ahora pone un savepoint en cada sentencia? Ese comportamiento NO es de Postgres. (Aclaro que no considero que el driver ODBC sea de Postgres). -- Alvaro Herrera Vendo parcela en Valdivia: http://alvherre.cl/caboblanco "Endurecerse, pero jamás perder la ternura" (E. Guevara) -- TIP 5: ¿Has leído nuestro extenso FAQ? http://www.postgresql.org/docs/faqs.FAQ.html
