perf(replication): implement async processing during replication by ygxio · Pull Request #1166 · pgdogdev/pgdog

ygxio · 2026-07-08T19:09:17Z

fixes #1036

ygxio · 2026-07-08T19:09:59Z

I am still working on the design for it, just a peak if the direction seems well @levkk

levkk · 2026-07-08T19:14:58Z

Cool! Would be good to see some benchmark numbers, just to get a sense of how much faster this is.

ygxio · 2026-07-08T19:16:14Z

Do you have any such setup so that i can benchmark it?

codecov · 2026-07-08T19:19:44Z

Codecov Report

❌ Patch coverage is 93.39207% with 30 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...backend/replication/logical/subscriber/pipeline.rs	95.01%	20 Missing ⚠️
...c/backend/replication/logical/subscriber/stream.rs	82.69%	9 Missing ⚠️
pgdog/src/backend/replication/logical/error.rs	0.00%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

levkk · 2026-07-08T19:23:28Z

Do you have any such setup so that i can benchmark it?

This might work:

benches/bench.sh

Specifically, see resharding folder.

ygxio · 2026-07-08T19:38:48Z

PGDOG_BIN=/tmp/pgdog-new bash benches/resharding/replication/run.sh --baseline main

ygxio · 2026-07-08T19:59:27Z

For BENCH_SCALE = 3000, DEST_LATENCY_MS=10 we have more performance boosts

ygxio · 2026-07-08T20:07:18Z

RUNS = 2
WARMUP = 1
BENCH_SCALE = 5000
DEST_LATENCY_MS = 10
USE_TOXI = 1

@levkk results seems good but also too good at a point

levkk · 2026-07-08T20:11:56Z

Async should be a big improvement, so not that surprising. This is very cool. Let me know when you're ready for a review, I'll tag Kiryl.

ygxio · 2026-07-13T11:30:08Z

@levkk ready for review

meskill · 2026-07-15T22:32:04Z

+}
+
+#[cfg(test)]
+mod test {


Do you think we should add more unit tests here? I think we should have some for testing the whole flow - prepare -> execute -> await. And also some tests for possible errors

Sure @meskill would add more tests

We still miss some important tests:

error path - something that will trigger an error response, validate that we get the error properly and we won't block the execution for future calls

missed rows calculation - just some calls to generate missed rows and make sure we get proper stats for it

ygxio · 2026-07-16T11:37:32Z

@meskill i have added a few more could you take a look?

meskill · 2026-07-17T15:42:06Z

Thanks @ygxio I'm still checking the code more deeply, but anyway looking great so far.

Putting my bench results to confirm the improvements:

Against main

With defaults:

With toxi and latency for source/destination for 1ms:

Separately

And the next without comparison with main (compare against prev run) since since it is executing too long to get the result.

With latency 10ms:

With latency 100ms:

ygxio · 2026-07-17T15:54:05Z

i see from 1 to 10 to 100 ms of latency the jump has been pretty high, need to see the cause maybe

meskill · 2026-07-19T19:35:17Z

+}
+
+#[cfg(test)]
+mod test {


We still miss some important tests:

error path - something that will trigger an error response, validate that we get the error properly and we won't block the execution for future calls

missed rows calculation - just some calls to generate missed rows and make sure we get proper stats for it

ygxio · 2026-07-20T18:38:48Z

DEFAULT

Src/dest latecy = 1 ms

Src/dest latecy = 10 ms

Src/dest latecy = 100 ms

Looks like almost same performance

ygxio · 2026-07-21T18:30:39Z

have fixed most of the issues, need a re review @levkk @meskill

meskill

Looks good, only the small test fix and we'll merge

meskill · 2026-07-23T15:06:56Z

+    async fn prepare_invalid_sql_sync_returns_error() {
        let server = test_server().await;
        let conn = PipelinedConnection::new(server).unwrap();

-        // A single in-transaction prepare with several statements uses
-        // ParseAcks(n): the waiter must resolve only after ALL n ParseComplete
-        // acks arrive (exercises the n -> 0 countdown, not just n == 1).
-        conn.prepare(
-            &[
-                Parse::named("__pipe_m1", "SELECT $1::bigint"),
-                Parse::named("__pipe_m2", "SELECT $1::text"),
-                Parse::named("__pipe_m3", "SELECT $1::bool"),
-            ],
-            true,
+        // Out-of-transaction prepare of invalid SQL: Postgres replies with an
+        // ErrorResponse, which is latched and surfaced through the Sync path.
+        let err = conn
+            .prepare(&[Parse::named("__pipe_bad", "NOT VALID SQL")], false)
+            .await
+            .unwrap_err();
+        assert!(
+            matches!(err, Error::PgError(_)),
+            "unexpected error: {err:?}"
+        );
+        // The error was taken while surfacing, so nothing remains latched.
+        assert!(conn.take_error().is_none());
+    }
+
+    #[tokio::test]
+    async fn prepare_invalid_sql_flush_returns_error() {
+        let server = test_server().await;
+        let conn = PipelinedConnection::new(server).unwrap();
+
+        // In-transaction prepare uses Flush, so Postgres sends no ReadyForQuery
+        // on error. The parked ParseAcks waiter can only be released by the
+        // 'E' handler's wake_all(): this proves the prepare does not hang.
+        let err = conn
+            .prepare(&[Parse::named("__pipe_bad", "NOT VALID SQL")], true)
+            .await
+            .unwrap_err();
+        assert!(
+            matches!(err, Error::PgError(_)),
+            "unexpected error: {err:?}"
+        );
+        assert!(conn.take_error().is_none());
+    }


those are identical tests, please verify

@meskill one it for out of transaction and other is for in transaction, should i merge them into one test with a loop over in_transaction value either false or true

ygxio changed the title ~~faster replication v1~~ faster replication Jul 8, 2026

ygxio changed the title ~~faster replication~~ feat: faster replication Jul 13, 2026

levkk requested a review from meskill July 13, 2026 17:42

meskill reviewed Jul 15, 2026

View reviewed changes

meskill requested changes Jul 19, 2026

View reviewed changes

ygxio added 8 commits July 20, 2026 15:46

faster replication v1

d4b9003

cosmetic changes

b6a5e1c

minor correction

99b2b7b

making clippy happy

094965f

making fmt happy

9a54028

a few tests

81d54a9

single queue v1

f55c60d

bias for read server branch

0c5844d

ygxio force-pushed the faster-replication branch from 8cf5e8b to 0c5844d Compare July 20, 2026 10:16

ygxio added 2 commits July 20, 2026 16:29

fix broken tests

0bd970a

some refactor and join all

acd64ed

cleanup, fixes and tests

b6331cd

meskill changed the title ~~feat: faster replication~~ perf(replication): implement async processing during replication Jul 23, 2026

meskill requested changes Jul 23, 2026

View reviewed changes

Uh oh!

Conversation

ygxio commented Jul 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ygxio commented Jul 8, 2026

Uh oh!

levkk commented Jul 8, 2026

Uh oh!

ygxio commented Jul 8, 2026

Uh oh!

codecov Bot commented Jul 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

levkk commented Jul 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ygxio commented Jul 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ygxio commented Jul 8, 2026

Uh oh!

ygxio commented Jul 8, 2026

Uh oh!

levkk commented Jul 8, 2026

Uh oh!

ygxio commented Jul 13, 2026

Uh oh!

meskill Jul 15, 2026

Choose a reason for hiding this comment

Uh oh!

ygxio Jul 16, 2026

Choose a reason for hiding this comment

Uh oh!

meskill Jul 19, 2026

Choose a reason for hiding this comment

Uh oh!

ygxio commented Jul 16, 2026

Uh oh!

meskill commented Jul 17, 2026

Against main

Separately

Uh oh!

ygxio commented Jul 17, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

meskill Jul 19, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

ygxio commented Jul 20, 2026

Uh oh!

ygxio commented Jul 21, 2026

Uh oh!

meskill left a comment

Choose a reason for hiding this comment

Uh oh!

meskill Jul 23, 2026

Choose a reason for hiding this comment

Uh oh!

ygxio Jul 23, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

ygxio commented Jul 8, 2026 •

edited

Loading

codecov Bot commented Jul 8, 2026 •

edited

Loading

levkk commented Jul 8, 2026 •

edited

Loading

ygxio commented Jul 8, 2026 •

edited

Loading