From: | Thomas Antepoth <t_antepoth(at)hamm(dot)netsurf(dot)de> |
---|---|
To: | pgsql-general(at)postgreSQL(dot)org |
Subject: | Re: [GENERAL] Replication of databases (esp. postgres) |
Date: | 1999-02-16 04:15:56 |
Message-ID: | Pine.LNX.3.96.990216045619.5637A-100000@ns.c-c.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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++
From | Date | Subject | |
---|---|---|---|
Next Message | Clark Evans | 1999-02-16 04:29:48 | How about a contract? (Was: Re: [GENERAL] A book for PgSQL? A need? yes? no?) |
Previous Message | Gregory Maxwell | 1999-02-16 00:14:13 | Re: [GENERAL] Two Machines - Question |