Re: Proposal: Commit timestamp - Mailing list pgsql-hackers

On 1/25/2007 6:49 PM, Tom Lane wrote:
> Jan Wieck <JanWieck@Yahoo.com> writes:
>> To provide this data, I would like to add another "log" directory, 
>> pg_tslog. The files in this directory will be similar to the clog, but 
>> contain arrays of timestamptz values.
> 
> Why should everybody be made to pay this overhead?

It could be made an initdb time option. If you intend to use a product 
that requires this feature, you will be willing to pay that price.

> 
>> The COMMIT syntax will get extended to
>>     COMMIT [TRANSACTION] [WITH TIMESTAMP <timestamptz>];
>> The extension is limited to superusers and will override the normally 
>> generated commit timestamp. This will be used to give the replicating 
>> transaction on the replica the exact same timestamp it got on the 
>> originating master node.
> 
> I'm not convinced you've even thought this through.  If you do that then
> you have no guarantee of commit timestamp monotonicity on the slave
> (if it has either multi masters or any locally generated transactions).
> Since this is supposedly for a multi-master system, that seems a rather
> fatal objection --- no node in the system will actually have commit
> timestamp monotonicity.  What are you hoping to accomplish with this?

Maybe I wasn't clear enough about this. If the commit timestamps on the 
local machine are guaranteed to increase at least by one millisecond 
(okay that limits the system to a sustained 1000 commits per second 
before it really seems to run ahead of time), then no two commits on the 
same instance will ever have the same timestamp. If furthermore each 
instance in a cluster has a distinct priority (the microsecond part 
added to the millisecond-truncated timestamp), each commit timestamp 
could even act as a globally unique ID. It does require that all the 
nodes in the cluster are configured with a distinct priority.

What I hope to accomplish with this is a very easy, commit time based 
"last update wins" conflict resolution for data fields of the overwrite 
nature.

The replication system I have in mind will have another field type of 
the balance nature, where it will never communicate the current value 
but only deltas that get applied regardless of the two timestamps.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #