DAntonio,

http://www.postgresql.org/docs/9.2/static/sql-prepare-transaction.html

вы наверняка решаете не ту задачу и не так.

двухфазный коммит нужен при реализации менеджеров распределенных траназакций.

какая у вас исходная проблема? зачем вам всё это?

DAntonio,

вообще-то никак.

для подобных проблем, согласование транзакционных машин, имеются два рабочих подхода.

1) менеджеры распределенных транзакций, внутри которых протокол двухфазный как раз и еще немного всякой требухи.
2) "транзакционные" очереди - ивентуал-консиcтенси.

--

1)

http://en.wikipedia.org/wiki/Two-phase_commit
http://ru.wikipedia.org/wiki/XA_Транзакции

и данная штука вам, в том числе, будет обеспечивать, что система может достигать состояния, когда все вовлеченные в X-транзакцию транзакции-внутри-узлов могут быть в будущем гарантированно закоммиченны (на второй фазе как раз).

при этом "синхронность" второй фазы вам никто не обещает. и суть, каждая i-ая транзакционная машина сама по себе ничего не знает о глобальном замысле) и её состояние может быть не согласованно с состоянием глобальной X-транзакции, в том плане, что Х еще не закоммичена, а х-i-тая транзакция (на узле i которая) уже закоммичена.

вооот.

ну и вопрос с падениями/восстановлениями. после восстановлений любого из узлов и/или менеджера (который сам по себе тоже транзакционная машина - такая же база) - надо всё "чекать" на согласованность с менеджером. это сложно. но этого можно избежать если коммит синхронный с записью в вал. что, кстати, по дефолту в пг и в добавок может контролироваться с точностью до каждой конкретной транзакции.

--

2)

http://en.wikipedia.org/wiki/Eventual_consistency

тут суть в том, что событие создается в источнике, в той же транзакции локальной что и полезное действие. а потом уже событие доставляется на другой узел и там "проигрывается". (доставка асинхронная в общем виде всегда)

но тут получаем три момента.

2.1) всё может казаться более асинхронным, чем в первом варианте
2.2) можем получить аварию первого рода. на другом узле проигралось, а в источнике событие после этого не проапдейтилось. тогда событие придет еще раз в другой узел - надо быть к этому готовыми.
2.3) можем получить аварию второго рода. случилось "падение" источника, а восстановление в нём удалось не до самой последней транзакции. тогда возможно на другом узле уже успели проиграться события из "параллельной" вселенной, которая умерла. то есть события доставились, транзакции которых недовостановились в источнике. надо тоже проводить синхронизацию убежавшей в "несбыточное" будущее другой базы. ну или касательно падения другой базы, события из источника надо суметь сгенерить повторно, с момента до которого восстановили другую базу. но аварию второго рода можно так же избежать применяя везде синхронный коммит (как и в случае с падениями/востановлениями при распред транзакции).