Hi,
Simon Riggs wrote:
> There is no sync() during WAL apply when each individual transaction
> hits commit. This is because there is "no WAL" i.e. changes comes from
> WAL to the database, so we have no need of a second WAL to protect the
> changes being made.
Aha, that makes much more sense to me now. So you are not just using the
WAL to transfer changes, but the remote WAL replaces the one on the
standby completely.
Do you have replication to multiple slaves on the radar?
What I still don't understand is, why you are speaking about "logical"
replication. It rather sounds like an ordinary log shipping approach,
where the complete WAL is sent over the wire. Nothing wrong with that,
it certainly fits many needs and I welcome such a solution for Postgres.
In another thread, you are saying that application of the WAL on the
standby is "logical". This sounds like one could choose to skip certain
parts of the WAL on the standby, but still the complete WAL would have
to be sent. So this would only save a bit of i/o on the standby, right?
> Expensive as in we need to parse and handle each statement separately.
> If we have a single parameter then much lower overhead.
Is that really much of a concern when otherwise caring about network and
i/o latency? And what about sane default settings per session and
database, so you won't even need to explicitly set them for the majority
of transactions?
Regards
Markus
