Hi Stephen,
> 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?
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.
> 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.
[1]: https://github.com/afiskon/go-elector
--
Best regards,
Aleksander Alekseev