Hi, On 2020-06-18 13:24:38 -0400, Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: > > ... To go back to recovery rather than just to a read-only > > state, I think you'd need to grapple with some additional issues that > > patch doesn't touch, like some of the snapshot-taking stuff, but I > > think you still need to solve all of the problems that it does deal > > with, unless you're OK with killing every session. > > It seems like this is the core decision that needs to be taken. If > we're willing to have these state transitions include a server restart, > then many things get simpler. If we're not, it's gonna cost us in > code complexity and hence bugs. Maybe the usability gain is worth it, > or maybe not. > > I think it would probably be worth the trouble to pursue both designs in > parallel for awhile, so we can get a better handle on exactly how much > complexity we're buying into with the more ambitious definition.
What I like about ALTER SYSTEM READ ONLY is that it basically would likely be a part of both a restart and a non-restart based implementation. I don't really get why the demote in this thread is mentioned as an alternative - it pretty obviously has to include a large portion of ALTER SYSTEM READ ONLY. The only part that could really be skipped by going straight to demote is a way to make ASRO invocable directly. You can simplify a bit more by killing all user sessions, but at that point there's not that much upshot for having no-restart version of demote in the first place. The demote patch in this thread doesn't even start to attack much of the real complexity around turning a primary into a standby. To me the complexity of a restartless demotion are likely worth it. But it doesn't seem feasible to get there in one large step. So adding individually usable sub-steps like ASRO makes sense imo. Greetings, Andres Freund