Re: GSoC 2018 - Mailing list pgsql-hackers
From | Stephen Frost |
---|---|
Subject | Re: GSoC 2018 |
Date | |
Msg-id | 20171215144258.GJ4628@tamriel.snowman.net Whole thread Raw |
In response to | Re: GSoC 2018 (Alex Kliukin <alexk@hintbits.com>) |
List | pgsql-hackers |
Alex, * Alex Kliukin (alexk@hintbits.com) wrote: > On Fri, Dec 15, 2017, at 14:30, Stephen Frost wrote: > > * Aleksander Alekseev (a.alekseev@postgrespro.ru) wrote: > > > > > 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. > > Does it make sense to address the limitations of the logical > replication first, i.e. inability to replicate DDL, sequences and so on? This is what I was trying to get at earlier, which was mostly just around trying to scope the project down to something a bit more reasonable since the initial proposal sounded like it could be a whole new and independent OSS project on its own. > > 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. > > Right now logical replication and physical replication-based HA tools > don't work together nicely, since logical replication position is not > propagated to the promoted replica (I think Craig Ringer has been > tackling this issue for a few releases already, the latest set of > patches I could find is https://commitfest.postgresql.org/15/788/). > Perhaps there is opportunity for a GSoC student to help fixing it. Until > then we cannot use logical replication for HA, and even doing something > simpler like automating creation of logical replicas in Patroni makes > little sense, as they are doomed to be reinitialized on every failover. This also sounds like a good project for a GSoC student. To be clear, we can certainly have project ideas on the Ideas page which build on things that aren't yet committed or to help with existing projects that are already underway. The project needs to be the right level of effort (remember- this will be the student's job for 12 weeks) and needs to be something that a student would be able to come up to speed on and make serious and meaningful progress on during their summer. When it comes to timeline, student proposals start being accepted in March. Thanks! Stephen
Attachment
pgsql-hackers by date: