On 10/11/14 08:01, Anssi Kääriäinen wrote:
> On Sun, 2014-11-09 at 11:57 -0500, Steve Singer wrote:
>
>> The reason why Jim and myself are asking for the LSN and not just the
>> timestamp is that I want to be able to order the transactions. Jim
>> pointed out earlier in the thread that just ordering on timestamp allows
>> for multiple transactions with the same timestamp.
>>
>> Maybe we don't need the entire LSN to solve that. If you already have
>> the commit timestamp maybe you only need another byte or two of
>> granularity to order transactions that are within the same microsecond.
>
> There is no guarantee that a commit with later LSN has a later
> timestamp. There are cases where the clock could move significantly
> backwards.
>
> A robust solution to storing transaction commit information (including
> commit order) in a way that can be referenced from other tables, can be
> loaded to another cluster, and survives crashes would be a great
> feature. But this feature doesn't have those properties.
>
It has the property of surviving crashes.
Not sure what you mean by referencing from other tables?
And about loading to another cluster, the txid does not really have any
meaning on another cluster, so the info about it does not have either?
But anyway this patch is targeting extensions not DBAs - you could write
extension that will provide that feature on top of this patch (although
given what I wrote above I don't see how it's useful).
-- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services
