Re: Global snapshots - Mailing list pgsql-hackers

From Andrey V. Lepikhov
Subject Re: Global snapshots
Date
Msg-id f23083b9-38d0-6126-eb6e-091816a78585@postgrespro.ru
Whole thread Raw
In response to Re: Global snapshots  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Global snapshots
List pgsql-hackers
On 6/19/20 11:48 AM, Amit Kapila wrote:
> On Wed, Jun 10, 2020 at 8:36 AM Andrey V. Lepikhov
> <a.lepikhov@postgrespro.ru> wrote:
>> On 09.06.2020 11:41, Fujii Masao wrote:
>>> The patches seem not to be registered in CommitFest yet.
>>> Are you planning to do that?
>> Not now. It is a sharding-related feature. I'm not sure that this
>> approach is fully consistent with the sharding way now.
> Can you please explain in detail, why you think so?  There is no
> commit message explaining what each patch does so it is difficult to
> understand why you said so?
For now I used this patch set for providing correct visibility in the 
case of access to the table with foreign partitions from many nodes in 
parallel. So I saw at this patch set as a sharding-related feature, but 
[1] shows another useful application.
CSN-based approach has weak points such as:
1. Dependency on clocks synchronization
2. Needs guarantees of monotonically increasing of the CSN in the case 
of an instance restart/crash etc.
3. We need to delay increasing of OldestXmin because it can be needed 
for a transaction snapshot at another node.
So I do not have full conviction that it will be better than a single 
distributed transaction manager.
   Also, can you let us know if this
> supports 2PC in some way and if so how is it different from what the
> other thread on the same topic [1] is trying to achieve?
Yes, the patch '0003-postgres_fdw-support-for-global-snapshots' contains 
2PC machinery. Now I'd not judge which approach is better.
  Also, I
> would like to know if the patch related to CSN based snapshot [2] is a
> precursor for this, if not, then is it any way related to this patch
> because I see the latest reply on that thread [2] which says it is an
> infrastructure of sharding feature but I don't understand completely
> whether these patches are related?
I need some time to study this patch. At first sight it is different.
> 
> Basically, there seem to be three threads, first, this one and then
> [1] and [2] which seems to be doing the work for sharding feature but
> there is no clear explanation anywhere if these are anyway related or
> whether combining all these three we are aiming for a solution for
> atomic commit and atomic visibility.
It can be useful to study all approaches.
> 
> I am not sure if you know answers to all these questions so I added
> the people who seem to be working on the other two patches.  I am also
> afraid that if there is any duplicate or conflicting work going on in
> these threads so we should try to find that as well.
Ok
> 
> 
> [1] -
https://www.postgresql.org/message-id/CA%2Bfd4k4v%2BKdofMyN%2BjnOia8-7rto8tsh9Zs3dd7kncvHp12WYw%40mail.gmail.com
> [2] - https://www.postgresql.org/message-id/2020061911294657960322%40highgo.ca
> 

[1] 
https://www.postgresql.org/message-id/flat/20200301083601.ews6hz5dduc3w2se%40alap3.anarazel.de

-- 
Andrey Lepikhov
Postgres Professional
https://postgrespro.com



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: More tzdb fun: POSIXRULES is being deprecated upstream
Next
From: Fujii Masao
Date:
Subject: Re: Review for GetWALAvailability()