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

From Kirill Reshke
Subject Re: Built-in Raft replication
Date
Msg-id CALdSSPgzhXTsY4UF-S2AsJwVBMvTSn1sB+Lc9jOcnQ8x3ebktg@mail.gmail.com
Whole thread Raw
In response to Built-in Raft replication  (Konstantin Osipov <kostja.osipov@gmail.com>)
Responses Re: Built-in Raft replication
Re: Built-in Raft replication
List pgsql-hackers
On Mon, 14 Apr 2025 at 22:15, Konstantin Osipov <kostja.osipov@gmail.com> wrote:
>
> Hi,

Hi

> I am considering starting work on implementing a built-in Raft
> replication for PostgreSQL.
>

Just some thought on top of my mind, if you need my voice here:

I have a hard time believing the community will be positive about this
change in-core. It has more changes as contrib extension. In fact, if
we want a built-in consensus algorithm, Paxos is a better option,
because you can use postgresql as local crash-safe storage for single
decree paxos, just store your state (ballot number, last voice) in a
heap table.
OTOH Raft needs to write its own log, and what's worse, it sometimes
needs to remove already written parts of it (so, it is not appended
only, unlike WAL). If you have a production system which maintains two
kinds of logs with different semantics, it is a very hard system to
maintain..

There is actually a prod-ready (non open source) implementation of
RAFT as extension, called BiHA, by pgpro.

Just some thought on top of my mind, if you need my voice here.

-- 
Best regards,
Kirill Reshke



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Fundamental scheduling bug in parallel restore of partitioned tables
Next
From: Robert Haas
Date:
Subject: Re: BitmapHeapScan streaming read user and prelim refactoring