After fighting crash after crash with pgcopydb v17 and v18 I decided to bite the bullet and write my own in Golang.
I picked Golang because most issues with pgcopydb were related to concurrency bugs and memory leaks. There is nothing in this tool that requires C, Golang is totally fine and comes with a good concurrency built-in and a garbage collector.
A few more notable improvements:
- I use binary format instead wal2json
- Optional control plane with web interface
- CDC replay runs concurrently (partition by fk)
I had a very similar story back pre-Go-v1, was frustrated trying to debug a C memory leak in concurrent code. Switched to Go in a few weeks, less code, no bugs in this realm, more features. I was hooked and have been a proud gopher since
I assume you have reported the issues / crashes to pgcopydb. Wasn't it easier to fix them rather than rewriting from scratch? I assume rewrite was heavily AI driven, and if so, probably AI could have fixed pgcopydb rather than rewriting.
Yeah, and I don't see how that changes my question, which still holds: did you try to fix the first project, and report the issues, before doing a full rewrite?
5 comments
[ 0.19 ms ] story [ 7.3 ms ] threadI picked Golang because most issues with pgcopydb were related to concurrency bugs and memory leaks. There is nothing in this tool that requires C, Golang is totally fine and comes with a good concurrency built-in and a garbage collector.
A few more notable improvements:
- I use binary format instead wal2json - Optional control plane with web interface - CDC replay runs concurrently (partition by fk)
Or am I missing something?
OP is the project maintainer