On Thu, May 05, 2011 at 09:22:14PM -0600, Joshua Tolley wrote: > course, but it is trigger based. One notable difference between Bucardo and > Slony is that whereas Slony's triggers store the entire row data in a separate > log table when something changes, Bucardo stores only the primary key. That's interesting. An earlier replication system we had at Afilias (erserver, which was descended from the rserv code that used to be in contrib/) used this strategy.[1] I liked to distinguish between the "latest consistent data" strategy and the "logical order application" strategy. There are some advantages to the latest consistent data strategy, the greatest of which is that you don't get the "lag" problems. Under Slony, you have to capture all the state between the last replication sync and the current one, even if there are multiple changes to the same row. There is a problem, however, in that if you want to use your replica to capture various changes along the way, you can't do it. Moreover, there's no guarantee under such a system that your replica is ever consistent with the way a given _client_ saw the database (there is a guarantee that it is consistent with some database state on the master, of course, but not a guarantee that it ever looks just as a client would have seen it at the moment of the client's action). These two counter-considerations were among the things that made the erserver strategy undesirable from my point of view given what we were trying to do at Afilias at the time. So that's why I was happy we changed direction with Slony. (But that decision came with its own complications.) A [1] The code is still hanging around somewhere, I think, mostly as an example of what not to do. For instance: copying entire result sets into memory and them sorting them is a bad idea. Also, if someone imposes on you a programmer you are fairly sure doesn't understand the problem you're working on, you should quit on the spot. (I have to keep relearning this one, though.) -- Andrew Sullivan ajs@xxxxxxxxxxxxxxx -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
