Re: POC and rebased patch for CSN based snapshots

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?

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

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

---
Regards,

Highgo Software (Canada/China/Pakistan)

URL : http://www.highgo.ca/

EMAIL: mailto:movead(dot)li(at)highgo(dot)ca