From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>
Cc: tsunakawa.takay@fujitsu.com <tsunakawa.takay@fujitsu.com>
Cc: Andrey V. Lepikhov <a.lepikhov@postgrespro.ru>
Cc: movead.li@highgo.ca <movead.li@highgo.ca>
Cc: PostgreSQL-Dev <pgsql-hackers@postgresql.org>
Subject: Re: Global snapshots
Date: Wed, 28 Oct 2020 16:00:27 +0900
Message-ID: <f59e3cf8-84d7-4a2b-218d-48ffac488566@oss.nttdata.com> (raw)
In-Reply-To: <CA+fd4k5d9Jjt2zwCFwm9FmFF1m6J1_ixaU_X7noM9qkDWCbAzA@mail.gmail.com>
References: <07b2c899-4ed0-4c87-1327-23c750311248@postgrespro.ru>
<CAA4eK1+tMDXU9WtQ0kRgyk1jPr+K-7FowMdFB8=t-ptUEQa-mQ@mail.gmail.com>
<CA+fd4k6YTa25VxpsqvpvqZmsCErT5T8=MYNNDXt7Wn0DsJvSrg@mail.gmail.com>
<CAA4eK1KAB=YbvDd3a8g2qNj2QNrQANnrpNmoaNCtEMLfaiFjrg@mail.gmail.com>
<TYAPR01MB2990E83F9E886A9C8AB8E269FE760@TYAPR01MB2990.jpnprd01.prod.outlook.com>
<TYAPR01MB29902D8B671A5A6946F5AEA8FE720@TYAPR01MB2990.jpnprd01.prod.outlook.com>
<806c3708-26ea-b94d-87b1-d48e41e93726@postgrespro.ru>
<TYAPR01MB2990F6F2A75657899A7E3A30FE270@TYAPR01MB2990.jpnprd01.prod.outlook.com>
<d17da3c0-54bb-6221-7ec7-151f6be39e5f@oss.nttdata.com>
<TYAPR01MB299093D3F5E8BC2D80D5DFD6FE270@TYAPR01MB2990.jpnprd01.prod.outlook.com>
<88a2642f-1ce6-a9d2-5d26-1221a2c4e072@oss.nttdata.com>
<CAA4eK1LMQYtY1kJX5RpxkUCnrFnGqj--zcAGVH7Sp3mcPRRuvg@mail.gmail.com>
<dc6d5fe2-7bdf-1b3f-1027-e152b979c12f@oss.nttdata.com>
<CA+fd4k5d9Jjt2zwCFwm9FmFF1m6J1_ixaU_X7noM9qkDWCbAzA@mail.gmail.com>
On 2020/10/23 11:58, Masahiko Sawada wrote:
> On Thu, 15 Oct 2020 at 01:41, Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
>>
>>
>>
>> On 2020/09/17 15:56, Amit Kapila wrote:
>>> On Thu, Sep 10, 2020 at 4:20 PM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
>>>>
>>>>>> One alternative is to add only hooks into PostgreSQL core so that we can
>>>>>> implement the global transaction management outside. This idea was
>>>>>> discussed before as the title "eXtensible Transaction Manager API".
>>>>>
>>>>> Yeah, I read that discussion. And I remember Robert Haas and Postgres Pro people said it's not good...
>>>>
>>>> But it may be worth revisiting this idea if we cannot avoid the patent issue.
>>>>
>>>
>>> It is not very clear what exactly we can do about the point raised by
>>> Tsunakawa-San related to patent in this technology as I haven't seen
>>> that discussed during other development but maybe we can try to study
>>> a bit. One more thing I would like to bring here is that it seems to
>>> be there have been some concerns about this idea when originally
>>> discussed [1]. It is not very clear to me if all the concerns are
>>> addressed or not. If one can summarize the concerns discussed and how
>>> the latest patch is able to address those then it will be great.
>>
>> I have one concern about Clock-SI (sorry if this concern was already
>> discussed in the past). As far as I read the paper about Clock-SI, ISTM that
>> Tx2 that starts after Tx1's commit can fail to see the results by Tx1,
>> due to the clock skew. Please see the following example;
>>
>> 1. Tx1 starts at the server A.
>>
>> 2. Tx1 writes some records at the server A.
>>
>> 3. Tx1 gets the local clock 20, uses 20 as CommitTime, then completes
>> the commit at the server A.
>> This means that Tx1 is the local transaction, not distributed one.
>>
>> 4. Tx2 starts at the server B, i.e., the server B works as
>> the coordinator node for Tx2.
>>
>> 5. Tx2 gets the local clock 10 (i.e., it's delayed behind the server A
>> due to clock skew) and uses 10 as SnapshotTime at the server B.
>>
>> 6. Tx2 starts the remote transaction at the server A with SnapshotTime 10.
>>
>> 7. Tx2 doesn't need to wait due to clock skew because the imported
>> SnapshotTime 10 is smaller than the local clock at the server A.
>>
>> 8. Tx2 fails to see the records written by Tx1 at the server A because
>> Tx1's CommitTime 20 is larger than SnapshotTime 10.
>>
>> So Tx1 was successfully committed before Tx2 starts. But, at the above example,
>> the subsequent transaction Tx2 fails to see the committed results.
>>
>> The single PostgreSQL instance seems to guarantee that linearizability of
>> the transactions, but Clock-SI doesn't in the distributed env. Is this my
>> understanding right? Or am I missing something?
>>
>> If my understanding is right, shouldn't we address that issue when using
>> Clock-SI? Or the patch has already addressed the issue?
>
> As far as I read the paper, the above scenario can happen. I could
> reproduce the above scenario with the patch. Moreover, a stale read
> could happen even if Tx1 was initiated at server B (i.g., both
> transactions started at the same server in sequence). In this case,
> Tx1's commit timestamp would be 20 taken from server A's local clock
> whereas Tx2's snapshot timestamp would be 10 same as the above case.
> Therefore, in spite of both transactions were initiated at the same
> server the linearizability is not provided.
Yeah, so if we need to guarantee the transaction linearizability even
in distributed env (probably this is yes. Right?), using only Clock-SI
is not enough. We would need to implement something more
in addition to Clock-SI or adopt the different approach other than Clock-SI.
Thought?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: masao.fujii@oss.nttdata.com, masahiko.sawada@2ndquadrant.com, amit.kapila16@gmail.com, tsunakawa.takay@fujitsu.com, a.lepikhov@postgrespro.ru, movead.li@highgo.ca
Subject: Re: Global snapshots
In-Reply-To: <f59e3cf8-84d7-4a2b-218d-48ffac488566@oss.nttdata.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox