On 12/7/2010 1:45 PM, Steve Singer wrote:
> On 10-12-07 10:05 AM, Simon Riggs wrote:
>>  On Mon, 2010-12-06 at 15:25 -0500, Christopher Browne wrote:
>>>  Steve Singer<ssinger at ca.afilias.info>   writes:
>>
>>  Yes, if server crashes, many things will be lost.
>>
>>  It seems likely to me that there will few, if any, transactions for
>>  which we don't know the commit timestamp. All of the current
>>  transactions will be lost.
>>
>>  Do we really need the timestamp for every single transaction? Surely we
>>  can make a good guess from the transactions before and after.
>>
>
> If all your doing is building a replication system that moves the slave
> from one consistent snapshot to another then you can just group the
> transactions with no timestamp into the next commit and be fine.
>
> If one is trying to (as Chris alludes to) implement triggers on the
> slave that can use the commit timestamp then an approximation might not
> be good enough (depending on what these triggers are and the business
> requirements that have lead to them), but I am still unconvinced as to
> why you would want to use the commit timestamp (versus the timestamp of
> the individual operations) for something.

The commit timestamp is the moment in time, at which changes that the 
transaction made became visible to other sessions. That together with 
the CURRENT_TIMESTAMP of any serializable transaction will let you 
reconstruct EXACTLY the snapshot of the database, the serializable 
transaction saw.


Jan

-- 
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin