On Thu, Jul 27, 2017 at 5:08 AM, Stas Kelvich <s.kelv...@postgrespro.ru> wrote: > As far as I understand any solution that provides proper isolation for > distributed > transactions in postgres will require distributed 2PC somewhere under the > hood. > That is just consequence of parallelism that database allows — transactions > can > abort due concurrent operations. So dichotomy is simple: either we need 2PC or > restrict write transactions to be physically serial. > > In particular both Postgres-XL/XC and postgrespro multimaster are using 2PC to > commit distributed transaction.
Ah, OK. I was imagining that a transaction manager might be responsible for managing both snapshots and distributed commit. But if the transaction manager only handles the snapshots (how?) and the commit has to be done using 2PC, then we need this. > Also I see the quite a big value in this patch even without > tm/snapshots/whatever. > Right now fdw doesn’t guarantee neither isolation nor atomicity. And if one > isn’t > doing cross-node analytical transactions it will be safe to live without > isolation. > But living without atomicity means that some parts of data can be lost > without simple > way to detect and fix that. OK, thanks for weighing in. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
