On 11/16/2012 03:05 PM, Andres Freund wrote: >> I'd like to provide a comparison of the proposed change set format to >> the one used in Postgres-R. > > Uh, sorry to interrupt you right here, but thats not the "proposed > format" ;)
Understood. Sorry, I didn't mean to imply that. It's pretty obvious to me that this is more of a human readable format and that others, including binary formats, can be implemented. I apologize for the bad wording of a "proposed format", which doesn't make that clear. >> The Postgres-R approach is independent of WAL and its format, where as >> the approach proposed here clearly is not. Either way, there is a >> certain overhead - however minimal it is - which the former adds to the >> transaction processing itself, while the later postpones it to a >> separate XLogReader process. If there's any noticeable difference, it >> might reduce latency in case of asynchronous replication, but can only >> increase latency in the synchronous case. As far as I understood Andres, >> it was easier to collect the additional meta data from within the >> separate process. > > There also is the point that if you do the processing inside heap_* you > need to make sure the replication targeted data is safely received & > fsynced away, in "our" case thats not necessary as WAL already provides > crash safety, so should the replication connection break you can simply > start from the location last confirmed as being safely sent. In the case of Postgres-R, the "safely received" part isn't really handled at the change set level at all. And regarding the fsync guarantee: you can well use the WAL to provide that, without basing change set generation on in. In that regard, Postgres-R is probably the more general approach: you can run Postgres-R with WAL turned off entirely - which may well make sense if you take into account the vast amount of cloud resources available, which don't have a BBWC. Instead of WAL, you can add more nodes at more different locations. And no, you don't want your database to ever go down, anyway :-) >> In summary, I'd say that Postgres-R is an approach specifically >> targeting and optimized for multi-master replication between Postgres >> nodes, where as the proposed patches are kept more general. > > One major aim definitely was optionally be able to replicate into just > about any target system, so yes, I certainly agree. I'm glad I got that correct ;-) Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers