On Tuesday 08 August 2006 17:44, Christopher Browne wrote:
> Most databases that are interesting to replicate are implemented in C
> or C++, thereby implying that a suitably "deep" API needs to be
> implemented in C.
> In the case of PostgresQL, at least, operating in Java means that you
> need to operate at "arms length" from the database, which means the
> replication system is by no means tightly integrated.
Yes, PostgreSQL is the tough one here. Having a single-process multithreaded
PostgreSQL in which PL/Java would run in one global JVM would sure feel like
Note however that the problem is not Java, but any package that does not
expect the current PostgreSQL concurrency model. AFAIK Postgres-R has
same "arms length" architecture with an external process, probably for
compatibility with Spread.
We have however tried to minimize the inconvenience, even for PostgreSQL, by
doing the following:
1. Implementation was done in two layers, in which the PostgreSQL-specific one
is 100% Java-free and feature complete.
2. High level functionality (i.e. transaction priorities instead of directly
handling individual lock operations) reduce the number of round-trips to the
3. Event listeners in Java can be registered as non-blocking, thus putting the
external JVM out of the critical path except in a few critical operations.
Finally, although I concede that most databases that are interesting to
replicate are written in C or C++, these days, most are also getting tightly
coupled JVMs fairly high in their feature lists.
Jose Orlando Pereira
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not