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


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to