Re: Exposing the Xact commit order to the user

On 26/05/10 21:43, Jan Wieck wrote:
> On 5/26/2010 1:17 PM, Heikki Linnakangas wrote:
>> It would not get called during recovery, but I believe that would be
>> sufficient for Slony. You could always batch commits that you don't
>> know when they committed as if they committed simultaneously.
>
> Here you are mistaken. If the origin crashes but can recover not yet
> flushed to xlog-commit-order transactions, then the consumer has no idea
> about the order of those commits, which throws us back to the point
> where we require a non cacheable global sequence to replay the
> individual actions of those "now batched" transactions in an agreeable
> order.
>
> The commit order data needs to be covered by crash recovery.

Perhaps I'm missing something, but I thought that Slony currently uses a 
heartbeat, and all transactions committed between two beats are banged 
together and committed as one in the slave so that their relative commit 
order doesn't matter. Can we not do the same for commits missing from 
the commit-order log?

I'm thinking that the commit-order log would contain two kinds of records:

a) Transaction with XID X committed
b) All transactions with XID < X committed

During normal operation we write the 1st kind of record at every commit. 
After crash recovery (perhaps at the first commit after recovery or when 
the slon daemon first polls the server, as there's no hook for 
end-of-recovery), we write the 2nd kind of record.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com