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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
