Re: POC and rebased patch for CSN based snapshots - Mailing list pgsql-hackers

On 7/2/20 7:31 PM, Movead Li wrote:
> Thanks for the remarks,
> 
>  >Some remarks on your patch:
>  >1. The variable last_max_csn can be an atomic variable.
> Yes will consider.
> 
>  >2. GenerateCSN() routine: in the case than csn < csnState->last_max_csn
>  >This is the case when someone changed the value of the system clock. I
>  >think it is needed to write a WARNING to the log file. (May be we can do
>  >synchronization with a time server.
> Yes good point, I will work out a way to report the warning, it should 
> exist a
> report gap rather than report every time it generates CSN.
> If we really need a correct time? What's the inferiority if one node 
> generate
> csn by monotonically increasing?
Changes in time values can lead to poor effects, such as old snapshot. 
Adjusting the time can be a kind of defense.
> 
>  >3. That about global snapshot xmin? In the pgpro version of the patch we
>  >had GlobalSnapshotMapXmin() routine to maintain circular buffer of
>  >oldestXmins for several seconds in past. This buffer allows to shift
>  >oldestXmin in the past when backend is importing global transaction.
>  >Otherwise old versions of tuples that were needed for this transaction
>  >can be recycled by other processes (vacuum, HOT, etc).
>  >How do you implement protection from local pruning? I saw
>  >SNAP_DESYNC_COMPLAIN, but it is not used anywhere.
> I have researched your patch which is so great, in the patch only data
> out of 'global_snapshot_defer_time' can be vacuum, and it keep dead
> tuple even if no snapshot import at all,right?
> 
> I am thanking about a way if we can start remain dead tuple just before
> we import a csn snapshot.
> 
> Base on Clock-SI paper, we should get local CSN then send to shard nodes,
> because we do not known if the shard nodes' csn bigger or smaller then
> master node, so we should keep some dead tuple all the time to support
> snapshot import anytime.
> 
> Then if we can do a small change to CLock-SI model, we do not use the
> local csn when transaction start, instead we touch every shard node for
> require their csn, and shard nodes start keep dead tuple, and master node
> choose the biggest csn to send to shard nodes.
> 
> By the new way, we do not need to keep dead tuple all the time and do
> not need to manage a ring buf, we can give to ball to 'snapshot too old'
> feature. But for trade off, almost all shard node need wait.
> I will send more detail explain in few days.
I think, in the case of distributed system and many servers it can be 
bottleneck.
Main idea of "deferred time" is to reduce interference between DML 
queries in the case of intensive OLTP workload. This time can be reduced 
if the bloationg of a database prevails over the frequency of 
transaction aborts.
> 
> 
>  >4. The current version of the patch is not applied clearly with current
>  >master.
> Maybe it's because of the release of PG13, it cause some conflict, I will
> rebase it.
Ok
> 
> ---
> Regards,
> Highgo Software (Canada/China/Pakistan)
> URL : www.highgo.ca <http://www.highgo.ca/>
> EMAIL: mailto:movead(dot)li(at)highgo(dot)ca
> 
> 


-- 
regards,
Andrey Lepikhov
Postgres Professional