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(at)hamm(dot)netsurf(dot)de]
Sent: Monday, February 15, 1999 9:16 PM
To: pgsql-general(at)postgreSQL(dot)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++