Re: Transactions involving multiple postgres foreign servers, take 2

From: Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>
To: masahiko(dot)sawada(at)2ndquadrant(dot)com
Cc: amit(dot)kapila16(at)gmail(dot)com, m(dot)usama(at)gmail(dot)com, sulamul(at)gmail(dot)com, horikyota(dot)ntt(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org, sawada(dot)mshk(at)gmail(dot)com, alvherre(at)2ndquadrant(dot)com, thomas(dot)munro(at)gmail(dot)com, ildar(at)adjust(dot)com, horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp, chris(dot)travers(at)adjust(dot)com, robertmhaas(at)gmail(dot)com, tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com
Subject: Re: Transactions involving multiple postgres foreign servers, take 2
Date: 2020-06-14 08:51:14
Message-ID: 20200614.175114.1075341848185278404.t-ishii@sraoss.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>> Won't it create an inconsistency in viewing the data from the
>> different servers? Say, such a transaction inserts one row into a
>> local server and another into the foreign server. Now, if we follow
>> the above protocol, the user will be able to see the row from the
>> local server but not from the foreign server.
>
> Yes, you're right. This atomic commit feature doesn't guarantee such
> consistent visibility so-called atomic visibility. Even the local
> server is not modified, since a resolver process commits prepared
> foreign transactions one by one another user could see an inconsistent
> result. Providing globally consistent snapshots to transactions
> involving foreign servers is one of the solutions.

Another approach to the atomic visibility problem is to control
snapshot acquisition timing and commit timing (plus using REPEATABLE
READ). In the REPEATABLE READ transaction isolation level, PostgreSQL
assigns a snapshot at the time when the first command is executed in a
transaction. If we could prevent any commit while any transaction is
acquiring snapshot, and we could prevent any snapshot acquisition while
committing, visibility inconsistency which Amit explained can be
avoided.

This approach was proposed in a academic paper [1].

Good point with the approach is, we don't need to modify PostgreSQL at
all.

Downside of the approach is, we need someone who controls the timings
(in [1], a middleware called "Pangea" was proposed). Also we need to
limit the transaction isolation level to REPEATABLE READ.

[1] http://www.vldb.org/pvldb/vol2/vldb09-694.pdf

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2020-06-14 10:00:44 Re: Internal key management system
Previous Message Joseph Nahmias 2020-06-14 07:26:13 Re: create database with template doesn't copy ACL