RE: [GENERAL] Replication of databases (esp. postgres)

I was thinking about creating a trigger on every table that would write an
insert, update, or delete statement into a log file.  Each replicated
database would pro-actively read these and post them.

    -----Original Message-----
    From:    Thomas Antepoth [SMTP:t_antepoth@hamm.netsurf.de]
    Sent:    Monday, February 15, 1999 9:16 PM
    To:    pgsql-general@postgreSQL.org
    Subject:    Re: [GENERAL] Replication of databases (esp.
postgres)

    Dustin,


    thank you for your answer.

    On Mon, 15 Feb 1999, dustin sallings wrote:

    > // {Replication of r/w Databases in a two pass scheme w/
renumbering}
    >     Just one note.  Renumbering isn't all that important.  I did
one
    > that had a non-numeric unique ID for identity type columns.

    I thought of a field named db_id. This field combined with
    a unique (at least to the local database) counter should give a
    unique index to each relation.


    The rule to follow is: Every record in a relation with the
    same db_id and the same rec_id belongs together.


    But think of this situation:

    DB 1 gets a relation.

    table1        table2
    record1       record1
                  record2

    Now this relation gets replicated to DB 2.

    After this is done, DB 2 adds a record3 to
    table2 this relation.

    Question: Which db_id should DB 2 use?

    His own? In this way record3 wouldn't belong
    to this relation.

    The id of DB 1? In this way the data may
    not be unique to DB 1 as DB 1 might enter
    the same values for record3 for a completely
    other relation and a collision is created.

    So i dropped the idea of having a db_id field
    to identify the record of a relation w/o
    renumbering the relations by a master.


    have a nice day! t++