-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 >> 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] Yeah, I've talked with Jan about the similarities and differences between eserver and Bucardo. Seem philosophically simliar, although a bit diverged technically at this point. > 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). Not sure I really see why this is important. You mean as far as the fact that tables X, Y, and Z are in a replicated set, but client A makes changes to X and Y, and then client B makes changes to table Z, and thus Bucardo slurps in X, Y, and Z, but never as client A or B saw them? Any client connecting to the master after client B commits would have the same "problem", no? > [1] The code is still hanging around somewhere, I think, mostly > as an example of what not to do. Heh, I gotta look that up someday. - -- Greg Sabino Mullane greg@xxxxxxxxxxxx End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201105082255 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAk3HV7wACgkQvJuQZxSWSsg23wCfemaF8EBf58C47omG0Fc8TMeb WB4AoIZPZ57zDKLfoJ/wN2CFpUbQuq3k =CrQ3 -----END PGP SIGNATURE----- -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
