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@kilimandjaro.dyndns.org>