Re: [HACKERS] Transactions involving multiple postgres foreign servers - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] Transactions involving multiple postgres foreign servers
Date
Msg-id CA+TgmoaPsc7wQGp6h9aTiN6kAsTawHYsAiaBftJ6Vd7_vYYEUg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Transactions involving multiple postgres foreign servers  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
On Thu, Oct 26, 2017 at 4:11 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>> Why do we want the the backend to linger behind, once it has added its
>> foreign transaction entries in the shared memory and informed resolver
>> about it? The foreign connections may take their own time and even
>> after that there is no guarantee that the foreign transactions will be
>> resolved in case the foreign server is not available. So, why to make
>> the backend wait?
>
> Because I don't want to break the current user semantics. that is,
> currently it's guaranteed that the subsequent reads can see the
> committed result of previous writes even if the previous transactions
> were distributed transactions.

Right, this is very important, and having the backend wait for the
resolver(s) is, I think, the right way to implement it.

-- 
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

pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: [HACKERS] WIP: BRIN bloom indexes
Next
From: Julien Rouhaud
Date:
Subject: [HACKERS] unsafe tuple releasing in get_default_partition_oid