On 3/30/2016 2:52 PM, Francisco Reyes wrote:
On 03/30/2016 05:44 PM, John R Pierce wrote:
and what if commit db2 fails for any number of reasons? you've
already committed db1, so you can't roll it back. this sort of
work requires '2pc' (2-phase commit), which is rather gnarly to
implement.
You mean when executing the actual commit? Wouldn't that be a rare
ocurrence? Right now they are doing each DB independently and then
doing a cleanup if something goes wrong so even if there are times
where the "commit db2" fails, it would not be any worse than what they
have now.
fyi, you might look into...
http://www.postgresql.org/docs/current/static/sql-prepare-transaction.html
you'd begin the two transactions on the two seperate connections, do
whatever you need in both sessions, then prepare transaction on each
one, and if they both succeed, commit both, if either errors, rollback
the other.
re: your original question about connecting to two databases... ideally,
you'd merge both databases into seperate schemas on the same database,
then you can freely mix and match elements of both in your queries.
otherwise, foreign data wrappers are required (or FDW's predecessor,
dblink...).
--
john r pierce, recycling bits in santa cruz
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
