> Something that a in-core method might be able to do that an external one
> can't would be to support a method of uniquely identifying rows in
> tables with no PK's. A gross example (that undoubtedly wouldn't work in
> the real world) would be using TID's. A real-world implementation might
> be based on a hidden serial column.
Realistically you need more than a serial for MM replication. For each
row-version, you need:
serverID of last update
serialID of row
timestamp of last update
... and note that this would have to include deleted rows as well.
Currently Bucardo does this by using several fields, but you could put
together one 128-bit field which contains all of this information. Or
you could do an Intagram and compress it into 64 bits, but that would
require limiting the problem space in a way you probably can't do it for
a general tool.
I do agree that depending on user-defined PKs raises a whole host of
issues which we'd rather just sidestep, though.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
