Re: Re: AW: Re: MySQL and BerkleyDB (fwd)

> 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 collect consistent ordering information without
impacting performance too much ? Will ordering suffice to guarantee
correctness of the REDO ? (I mean, are there sources of
nondeterminism in PostgreSQL such as resource exhaustion etc. that I
should be aware of ?)
* would it be easier or harder to help implement 2-phase commit
inside PostgreSQL (but I am not quite a PostgreSQL hacker yet !)

Many thanks in advance !

--
<< Tout n'y est pas parfait, mais on y honore certainement les jardiniers >>

Dominique Quatravaux <dom(at)kilimandjaro(dot)dyndns(dot)org>