3 ms·

They're not using `wal_level = logical`, which has been the "friendly" way of doing CDC on Postgres since ever, but are going straight to `wal_level = replica`

by vmsp 16d ago

They're not using `wal_level = logical`, which has been the "friendly" way of doing CDC on Postgres since ever, but are going straight to `wal_level = replica` which, afaik, has never really been used to build something atop of except Postgres' own replication. This is very interesting. I'd never have guessed that it'd make such a difference. I also bet this is the sort of thing that would have never end up being implemented without access to coding agents. Having to figure out these protocol-level details is no longer the huge time sink it was

DenisM 16d ago
It’s probably brittle though? Replication implementation has to change in some ways from one version to another.
- saisrirampur 15d ago
  Right, it takes some effort, but it’s worth it for the benefits of sub-second latency and reduced operational overhead. We expect the WAL format for existing commands to remain relatively stable across Postgres versions, while newer commands may need additional handling.
saisrirampur 16d ago
Ack, thank you! The idea was to minimize the operational overhead of logical replication (slot growth, slowdowns from reorder buffering, handling advance schema changes) and reducing load on Postgres. This approach lets us purpose-build replication for ClickHouse. Postgres logical replication was primarily designed keeping in mind with Postgres as the target. There’s also some interesting work happening in core with a similar goal of decoupling logical decoding from the Postgres process. We plan to share learnings from WalShadow with the core and hopefully help bring this to Postgres someday :) https://hacking.postgres.tv/topics/logical-decoding/ https://hacking.postgres.tv/topics/logical-decoding/
__s 15d ago
we require wal_level=logical, would be nice to support looser in future agreed that there's a huge complexity cost to going this route

by vmsp 16d ago

DenisM 16d ago

It’s probably brittle though? Replication implementation has to change in some ways from one version to another.

saisrirampur 15d ago
Right, it takes some effort, but it’s worth it for the benefits of sub-second latency and reduced operational overhead. We expect the WAL format for existing commands to remain relatively stable across Postgres versions, while newer commands may need additional handling.

saisrirampur 16d ago

Ack, thank you! The idea was to minimize the operational overhead of logical replication (slot growth, slowdowns from reorder buffering, handling advance schema changes) and reducing load on Postgres. This approach lets us purpose-build replication for ClickHouse. Postgres logical replication was primarily designed keeping in mind with Postgres as the target. There’s also some interesting work happening in core with a similar goal of decoupling logical decoding from the Postgres process. We plan to share learnings from WalShadow with the core and hopefully help bring this to Postgres someday :) https://hacking.postgres.tv/topics/logical-decoding/ https://hacking.postgres.tv/topics/logical-decoding/

__s 15d ago

we require wal_level=logical, would be nice to support looser in future agreed that there's a huge complexity cost to going this route