Alex Vinogradovs wrote:
Now you're pointing out obvious problems. My company deals with data
warehouses, we don't really need to delete/update stuff, only
insert/select ;) But seriously, those issues can be handled if one
doesn't just send plain tuples, but also includes the information
about what kind of operations were performed. The receiving side
can then use primary keys to process deletes/updates. So the actual
solution might become way more flexible, it is only a question of
amount of development time put into its implementation...
If I understand what you are saying, this is how Replicator already does
replication (www.commandprompt.com). Inserts replication transactional
data, where updates and deletes replicate the low level command (what
was deleted/updated not the actual DML).
Joshua D. Drake
P.S. DDL is never a subject for replication (in normal RDBMS'es).
Alex.
On Sat, 2007-12-08 at 01:10 -0500, Greg Smith wrote:
On Fri, 7 Dec 2007, Alex Vinogradovs wrote:
The documents highlights possible problems with _SQL_ query intercepts.
I am talking about the actual tuples... i.e. row data rather than the
SQL requests.
The first two issues that come to mind are how to deal with a) deletions,
and b) changes to DDL (table creation etc.). Forwarding SQL handles those
but I'm not sure how your suggested scheme would. You should certainly
look at what went into the design of both the existing WAL replication and
tools like Slony to get an idea the full scale of challenges here.
--
* Greg Smith gsmith@xxxxxxxxxxxxx http://www.gregsmith.com Baltimore, MD
---------------------------(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
match
---------------------------(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
match
