> This 'pre-commit' 'really commit' two-step (get 'yer cowboy hats, right
> here) is what's needed, and is currently missing from pgsql.
Hello,
I'm very interested in this topic since I am involved in a
distributed, several-PostgreSQLs-backed, open-source,
buzzword-compliant database replication middleware (still in the draft
stage though --- this is not an announcement :-). I had thought that the pre-commit information could be stored in an
auxiliary table by the middleware program ; we would then have
to re-implement some sort of higher-level WAL (I thought of the list
of the commands performed in the current transaction, with a sequence
number for each of them that would guarantee correct ordering between
concurrent transactions in case of a REDO). But I fear I am missing
a number of important issues there ; so could you please comment on my
idea ? * what should I try not to forget to record in the higher-level WAL if I want consistency ? * how could one
collectconsistent ordering information without impacting performance too much ? Will ordering suffice to guarantee
correctnessof the REDO ? (I mean, are there sources of nondeterminism in PostgreSQL such as resource exhaustion etc.
thatI should be aware of ?) * would it be easier or harder to help implement 2-phase commit inside PostgreSQL (but I am
notquite a PostgreSQL hacker yet !)
Many thanks in advance !
--
<< Tout n'y est pas parfait, mais on y honore certainement les jardiniers >>
Dominique Quatravaux <dom@kilimandjaro.dyndns.org>