Hi, Simon Riggs wrote:
Reconstructing SQL from WAL, allowing logical apply. So yes, you're right, the actual replication of the data from one node to another is physical - its the final apply of the changes that is logical. So this fits neatly with our commitment to put synchronous replication into server.
Aha, thanks for your explanation.
It allows WAL to be used as the replication transport, which reduces the impact of tracking changes via triggers. The presence of commit records in the sequence can be used to parallelize the apply phase if required.
I note you are comparing against trigger based replication solutions.
I'm proposing to put the mechanisms in place to allow WAL to be used by other replication projects. Which turn out to be relatively small changes to the main server.
Comparing with the Postgres-R way to do it, there's a difference in the serialized change set format. Where Postgres-R uses it's a specialized format, you are proposing to use the existing WAL format to transfer change set data, which is architecture dependent and quite tightly bound to the physical format on disc. It cannot be changed to also carry other information required for replication, without having an impact on WAL for single node installations. I think the CPU load to serialize and deserialize is pretty similar and most probably negligible.
Regards Markus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
