On 2018-08-01 12:20:12 -0400, Alvaro Herrera wrote: > Hello > > On 2018-Aug-01, Andres Freund wrote: > > > My problem isn't just that I shouldn't think this should be committed > > without at least a firm committement to do better, > > I take "I think this shouldn't be committed" is what you meant.
Yep. > I'm not sure I agree with this line of argument. The reality is that > real life or diverging priorities preclude people from working on > $stuff. Right. > This is a useful feature-1 we have here, and if we stall it > until we have feature-2, we may not get either until a year later. > That's not a great outcome. We didn't wait for partitioning, parallel > query, DDL progress reporting, logical replication, JIT, wait events (to > name but a few) to solve world's hunger in order to start getting > committed. We move forward step by step, and that's a good thing. But we asked that they implement something consistent, and rejected many that were not deemed to be that. > > my problem is that I think the "restart" approach is just using the > > entirely wrong hammer to solve the problem at hand. At the very least > > it's very problematic in respect to replicas, which need to know about > > the setting too, and can have similar problems the restart on the > > primary is supposed to prevent. > > If we define "restart" to mean taking all the servers down > simultaneously, that can be planned. It really can't realistically. That'd essentially mean breaking PITR. You'd have to schedule the restart of any replicas to happen after a specific record. And what if there's replicas that are on a delay? What if there's data centers that are currently offline? And again, this isn't hard to do properly. I don't get why we're talking about an at least operationally complex workaround when the proper solution isn't hard. Greetings, Andres Freund
