Fix broken link

[jfly]

I'm setting up zrepl on my homelab. As with every new thing, I first study our code for inspiration =)

Do we even want this? It's not necessary for transactional consistency (we already get that from zfs snapshots). From https://zrepl.github.io/configuration/snapshotting.html#postgres-checkpoint-hook

However, the Postgres manual recommends against checkpointing during normal operation. Further, the operation requires Postgres superuser privileges. zrepl users must decide on their own whether this hook is useful for them (it likely isn’t).

[vcunat]

I believe I had read the docs around this, but I don't recall such details anymore, except that at some point I also wondered if we want it.

[mweinelt]

We don't want the churn from the WAL in our backups, so the force a checkpoint. Every once in a while it would create unreasonable spikes between snapshots.

[jfly]

Every once in a while it would create unreasonable spikes between snapshots.

Ooh, spikes as in the number of changed blocks? This is about minimizing storage consumption?

[mweinelt]

Yes, storage consumption and time to sync the changes as function of the storage increase, which again increases the number of snapshots we need to keep before they can be pruned.

[jfly]

which again increases the number of snapshots we need to keep before they can be pruned.

Could you explain this? How would increased storage and slower syncs increase the number of snapshots we need to keep?

[mweinelt]

We can't delete snapshots that are not transfered yet.

[vcunat]

I wonder if this might interact badly with some long and large RW transactions which we produce (about half an hour on some evals, I think)