Subject: Re: Built-in Raft replication

From: Tom Lane <[email-masked]>
Date: Tue, 15 Apr 2025 19:19:42 -0400

Nikolay Samokhvalov <[email-masked]> writes:
> This is exactly what I wanted to write as well. The idea is great. At the
> same time, I think, consensus on many decisions will be extremely hard to
> reach, so this project has a high risk of being very long. Unless it's an
> extension, at least in the beginning.

Yeah.  The two questions you'd have to get past to get this into PG
core are:

1. Why can't it be an extension?  (You claimed it would work more
seamlessly in core, but I don't think you've made a proven case.)

2. Why depend on Raft rather than some other project?

Longtime PG developers are going to be particularly hard on point 2,
because we have a track record now of outliving outside projects
that we thought we could rely on.  One example here is the Snowball
stemmer; while its upstream isn't quite dead, it's twitching only
feebly, and seems to have a bus factor of 1.  Another example is the
Spencer regex engine; we thought we could depend on Tcl to be the
upstream for that, but for a decade or more they've acted as though
*we* are the upstream.  And then there's libxml2.  And uuid-ossp.
And autoconf.  And various documentation toolchains.  Need I go on?

The great advantage of implementing an outside dependency in an
extension is that if the depended-on project dies, we can say a few
words of mourning and move on.  It's a lot harder to walk away from
in-core features.

			regards, tom lane

---

From: Konstantin Osipov <[email-masked]>
Date: Wed, 16 Apr 2025 12:47:00 +0300

> seamlessly in core, but I don't think you've made a proven case.)

I think this can be best addressed when the discussion moves on to
an architecture design record, where the UX and implementation
details are outlined. I'm sure there can be a lot of bike-shedding
on that part. For now I merely wanted to know if:
- maybe there is a reason this will never be accepted
- maybe someone is already working on this.