Thread

Loading the complete thread in the background. This saved snapshot is available now. Refresh

1. vmsp · 1789593272 · focus · HN ↗

   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

   1. DenisM · 1789593533 · focus · HN ↗

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

      1. saisrirampur · 1789612203 · focus · HN ↗

         [dead]

   2. saisrirampur · 1789594513 · focus · HN ↗

      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 :) <a href="https:&#x2F;&#x2F;hacking.postgres.tv&#x2F;topics&#x2F;logical-decoding&#x2F;" rel="nofollow">https:&#x2F;&#x2F;hacking.postgres.tv&#x2F;topics&#x2F;logical-decoding&#x2F;

   3. __s · 1789671033 · focus · HN ↗

      we require wal_level=logical, would be nice to support looser in future

      agreed that there&#x27;s a huge complexity cost to going this route

2. rgbrgb · 1789595338 · focus · HN ↗

   [delayed]

   1. ZiiS · 1789597233 · focus · HN ↗

      Not this quick but better then polling: <a href="https:&#x2F;&#x2F;supabase.com&#x2F;features&#x2F;supabase-pipelines" rel="nofollow">https:&#x2F;&#x2F;supabase.com&#x2F;features&#x2F;supabase-pipelines
   2. saisrirampur · 1789612051 · focus · HN ↗

      WalShadow requires direct access to the physical WAL, and most managed Postgres providers don&#x27;t allow that. It works with ClickHouse Managed Postgres or self-hosted Postgres. I talk about this in the blog:

      Physical WAL is key to WalShadow’s architecture, but most managed Postgres services don’t expose it to customers, making it impossible to use WalShadow. ClickHouse Managed Postgres manages both sides of the stack, allowing us to integrate WalShadow directly into the Postgres replication layer and provide a native path from Postgres WAL to ClickHouse.

3. phroas · 1789629867 · focus · HN ↗

   Does this work with toast stored unchanged differently than logical? Or is it the same in terms need to merge with some last seen state of toasted field to project the whole of a changed tupled? Always a pita.

   1. __s · 1789671252 · focus · HN ↗

      yes toast is a pita. we&#x27;re currently working on 3 modes:

      1. disabled

      2. clickhouse, stores toast chunks on clickhouse then pulls them to resolve

      3. shadow, stores toast in shadow catalog, obviously less latency than clickhouse but demands disk space

Unofficial Hacker News client; not affiliated with Y Combinator.