Re: GSoC 2018

Aleksander,

* Aleksander Alekseev (a(dot)alekseev(at)postgrespro(dot)ru) wrote:
> > HA/fail-over is a very broad topic, with a lot of pieces that need to be
> > done such that I'm not sure it's really viable, but perhaps a precursor
> > project (synchronous logical replication seems like a prereq, no?) would
> > make more sense. Or, perhaps, a different piece of the HA question, but
> > solving the whole thing in a summer strikes me as unlikely to be
> > reasonable.
>
> Frankly I got the impression that logical replication in PostgreSQL 10
> is as synchronous as physical replication in terms that it treats
> synchronous_commit the same way and gives exactly same guarantees. Is
> there a problem with current implementation of logical replication I'm
> not aware of? Or by synchronous logical replication you meant something
> different?

synchronous_commit isn't the same as synchronous_standby_names ...

We could have used better names for those GUCs, I suspect.

> Regarding the difficulty of the project - in fact it's not that
> difficult. Particularly this project can rely on external tools, e.g.
> use Consul for service discovery and leader election based on
> leader-lease approach (implementation [1]). Having this the only thing
> is missing is automatic replica promoting and (optionally)
> re-configuring of HAProxy / pgbouncer / whatever. Yes, and lots of
> Jepsen-like test of course. I believe it's not such a complicated
> project.

What you're talking about is rebuilding Patroni, but adding more into it
than even Patroni tries to do, building it on Logical Replication
instead of physical replication, and calling it simple and something
that could get into core PostgreSQL over a 12 week GSoC project. I've
certainly got doubts about that, even if we decide that it'd be an
external-to-PG project (like Patroni).

What might be interesting is seeing if Logical Replication could be
added to Patroni as an option and then building on that.. Having
someone involved in the Patroni project would be the right way to go
about proposing that though to see what they think of it. That would
also be much more sensible as a GSoC project, since it'd be an addition
to an existing project and not more-or-less starting a whole new
project.

> > Regarding the thrift data type, that seems like a pretty good GSoC
> > project, though I'm not sure why you suggest having pl/pgsql functions
> > for accessing data from .thrift files- plpgsql can't directly access the
> > filesystem and the input routines for .thrift-style data would certainly
> > be best in C.
>
> What I meant was generating PL/pgSQL procedures from .thift files, like
> `MyStructure_getFieldX(bytea) returns text`. It took me a few hours to
> write pg_protobuf so I decided the project would be way to easy without
> implementing such tool. I changed the text on wiki, hopefully it's
> better now.

Wouldn't it make more sense to have something like what we have for
JSONB where there's operators that are used to pull out specific fields
instead of generated pl/pgsql procedures..?

Thanks!

Stephen