Skip to content

GORDA

Sections
Personal tools
You are here: Home » Community » ESCADA Replication Server » PostgreSQL/G

PostgreSQL/G

Document Actions
Implementation of the GORDA Interface in PostgreSQL.

Overview

PostgreSQL/G is a research prototype implementing the GORDA Architecture and Programming Interface (GAPI) natively on PostgreSQL. Note this is not a complete replication solution. A replication protocol, such as the ESCADA Replication Server, is required to achieve that.

The implementation of the GAPI natively on PostgreSQL is achieved in two steps. First, a set of patches to the PostgreSQL server and a trigger library provide the necessary functionality in a PostgreSQL specific fashion with minimal intrusion. Second, the GAPI interface is then exposed in a standalone Java process.

Download

PostgreSQL/G is distributed as a small package containing all code and documentation required to provide GAPI on PostgreSQL. It distributed under an open source BSD-like license. In order to put something running, the ESCADA Replication Server is required.

Status

Release 0.4, the PostgreSQL/G implementation of the GAPI provides:

  • There are no changes regarding this topic.

Release 0.3, the PostgreSQL/G implementation of the GAPI provides:

  • partial database and request contexts;
  • partial object-set processor.
  • integration with server-side Java through a sub-set of the PL-J.

Bugs fixed and Changes

Release 0.4 of the PostgreSQL/G implementation of the GAPI fixed the following bugs: - Fixed segmentation fault error when the number of connections exceeded the limit specified in the file postgresql.conf.

  • integration with maven.
  • integration with the ESCADA Toolkit (ESCADA Replication Server) through dependency injection.

Release 0.3 of the PostgreSQL/G implementation of the GAPI fixed the following bugs:

  • Fixed inconsistency in the database that was hindering the use of vacuum.
  • Fixed assertion problems.

Release 0.2 of the PostgreSQL/G implementation of the GAPI fixed the following bugs:

  • Recovery process uses "copy" instead of "sql statements";
  • High priority transactions do not causes deadlocks or busy-waiting.
  • Messages exchanged between the C-side and the Java-side are not corrupted by the priority mechanism.

Support

We welcome your feedback using the community mailing list.

Created by gorda
Last modified 2007-10-15 05:29 PM
 



Powered by Plone

This site conforms to the following standards: