Re: Built-in Raft replication - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Built-in Raft replication
Date
Msg-id 1798838.1744759182@sss.pgh.pa.us
Whole thread Raw
In response to Re: Built-in Raft replication  (Nikolay Samokhvalov <nik@postgres.ai>)
Responses Re: Built-in Raft replication
Re: Built-in Raft replication
List pgsql-hackers
Nikolay Samokhvalov <nik@postgres.ai> 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



pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: [18] Unintentional behavior change in commit e9931bfb75
Next
From: Jacob Champion
Date:
Subject: Re: dispchar for oauth_client_secret