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

From Andrey Borodin
Subject Re: Built-in Raft replication
Date
Msg-id 20FB597F-641F-48F8-8428-D8DDBA802D58@yandex-team.ru
Whole thread Raw
In response to Re: Built-in Raft replication  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Built-in Raft replication
Re: Built-in Raft replication
List pgsql-hackers

> On 16 Apr 2025, at 04:19, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> 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.

I think it's what Konstantin is proposing. To have our own Raft implementation, without dependencies.

IMO to better understand what is proposed we need some more description of proposed systems. How the new system will be
configured?initdb and what than? How new node joins cluster? What is running pg_rewind when necessary? 

Some time ago Peter E proposed to be able to start replication atop of empty directory, so that initial sync would be
morestraightforward. And also Heikki proposed to remove archive race condition when choosing new timeline. I think this
stepsare gradual movement in the same direction. 

My view is what Konstantin wants is automatic replication topology management. For some reason this technology is
calledHA, DCS, Raft, Paxos and many other scary words. But basically it manages primary_conn_info of some nodes to
providesome fault-tolerance properties. I'd start to design from here, not from Raft paper. 


Best regards, Andrey Borodin.


pgsql-hackers by date:

Previous
From: Alexander Lakhin
Date:
Subject: Re: recoveryCheck test failure on flaviventris
Next
From: Tom Lane
Date:
Subject: Re: Built-in Raft replication