From: | Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)ru> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Craig Ringer <craig(at)2ndquadrant(dot)com> |
Subject: | Re: logical decoding of two-phase transactions |
Date: | 2017-01-05 12:43:04 |
Message-ID: | DED204B8-0877-4BAB-B2FE-0F450BD56186@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 5 Jan 2017, at 13:49, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>
> Surely in this case the master server is acting as the Transaction
> Manager, and it knows the mapping, so we are good?
>
> I guess if you are using >2 nodes then you need to use full 2PC on each node.
>
> Please explain precisely how you expect to use this, to check that GID
> is required.
>
For example if we are using logical replication just for failover/HA and allowing user
to be transaction manager itself. Then suppose that user prepared tx on server A and server A
crashed. After that client may want to reconnect to server B and commit/abort that tx.
But user only have GID that was used during prepare.
> But even then, if you adopt the naming convention that all in-progress
> xacts will be called RepOriginId-EPOCH-XID, so they have a fully
> unique GID on all of the child nodes then we don't need to add the
> GID.
Yes, that’s also possible but seems to be less flexible restricting us to some
specific GID format.
Anyway, I can measure WAL space overhead introduced by the GID’s inside commit records
to know exactly what will be the cost of such approach.
--
Stas Kelvich
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2017-01-05 12:45:42 | Re: rewrite HeapSatisfiesHOTAndKey |
Previous Message | Ashutosh Bapat | 2017-01-05 12:38:17 | Re: Push down more full joins in postgres_fdw |