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
