Skip to content

coordinator: Reflect primary's dirty-status when logging repl cause

Patrick Steinhardt requested to merge pks-repl-logging-inconsistency into master

With commit d87747c8 (Consider primary modified only if a subtransaction was committed, 2021-05-14), we have changed replication logic to only trigger in case the primary is considered to have been dirtied. This was done such that we don't need to schedule replication jobs to secondaries in cases where we're sure that no user-visible change was performed anyway. The preexisting logging statements which inform about replication reasons haven't been adapted though, making it hard to see whether replication jobs were actually created or not based on the dirty status.

Improve the situation by discarding log messages in case the primary has not been dirtied.

Merge request reports