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