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)
EMAIL: mailto:movead(dot)li(at)highgo(dot)ca