Re: Transactions involving multiple postgres foreign servers

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Kevin Grittner <kgrittn(at)ymail(dot)com>
Cc: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Transactions involving multiple postgres foreign servers
Date: 2015-01-14 04:10:37
Message-ID: CA+TgmobUo+HWPFRNSCTa7j4GE43rpJPnNXdE5n6_ahCXdCfYjw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jan 8, 2015 at 1:00 PM, Kevin Grittner <kgrittn(at)ymail(dot)com> wrote:
>> Clearly, all the nodes other than the local one need to use 2PC. I am
>> unconvinced that the local node must write a 2PC state file only to
>> turn around and remove it again almost immediately thereafter.
>
> The key point is that the distributed transaction data must be
> flagged as needing to commit rather than roll back between the
> prepare phase and the final commit. If you try to avoid the
> PREPARE, flagging, COMMIT PREPARED sequence by building the
> flagging of the distributed transaction metadata into the COMMIT
> process, you still have the problem of what to do on crash
> recovery. You really need to use 2PC to keep that clean, I think.

I don't really follow this. You need to write a list of the
transactions that you're going to prepare to stable storage before
preparing any of them. And then you need to write something to stable
storage when you've definitively determined that you're going to
commit. But we have no current mechanism for the first thing (so
reusing 2PC doesn't help) and we already have the second thing (it's
the commit record itself).

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2015-01-14 04:28:35 Re: Transactions involving multiple postgres foreign servers
Previous Message Ashutosh Bapat 2015-01-14 04:00:22 Re: Parallel Seq Scan