public inbox for [email protected]  

help / color / mirror / Atom feed

From: Konstantin Osipov <[email protected]>
To: Kirill Reshke <[email protected]>
Cc: [email protected]
Subject: Re: Built-in Raft replication
Date: Mon, 14 Apr 2025 22:00:22 +0300
Message-ID: <Z_1bRq0wWJyIWvC5@ark> (raw)
In-Reply-To: <CALdSSPgzhXTsY4UF-S2AsJwVBMvTSn1sB+Lc9jOcnQ8x3ebktg@mail.gmail.com>
References: <Z_1Cq7JvabsFYjQo@ark>
	<CALdSSPgzhXTsY4UF-S2AsJwVBMvTSn1sB+Lc9jOcnQ8x3ebktg@mail.gmail.com>

* Kirill Reshke <[email protected]> [25/04/14 20:48]:
> > 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.

But Raft is a log replication algorithm, not a consensus
algorithm. It does use consensus, but that's for leader election.
Paxos could be used for log replication, but that would be
expensive. In fact etcd uses Raft, and etcd is used by Patroni. So
I completely lost your line of thought here.

> 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..

My proposal is exactly to replace (or rather, extend) the current
synchronous log replication with Raft. Entry removal is possible to
stack on top of append-only format, and production implementations
exist which do that.

So, no, it's a single log, and in fact the current WAL will do.

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

My guess biha is an extension since a proprietary code is easier
to maintain that way. I'd rather say the fact that there is a
proprietary implementation out in the field confirms it could be a
good idea to have it in PostgreSQL trunk. 

In any case I'm interested in contributing to the trunk, not
building a proprietary module/fork.

-- 
Konstantin Osipov

view thread (30+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: Built-in Raft replication
  In-Reply-To: <Z_1bRq0wWJyIWvC5@ark>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox