On Fri, 2021-06-11 at 13:15 -0400, Robert Haas wrote: > on it, but it seems to me that the comment does explain this, and > that > it's basically the same explanation as what Amit said.
It only addresses the "pro" side of the behavior, not the "con". It's a bit like saying "Given that we are in the U.S., it might seem like we should be driving on the right side of the road, but that side has traffic and we are in a hurry." Why might it seem that we should error out? If we don't error out, what bad things might happen? How do these "con"s weigh against the "pro"s? > I'm not sure that it would be a good > trade-off to have a tighter sanity check at the expense of adding > that > overhead. It doesn't add any overhead. All the client would have to do is "SELECT confirmed_flush_lsn FROM pg_replication_slots WHERE slot_name='myslot'", and compare it to the stored value. If the stored value is earlier than the confirmed_flush_lsn, the *client* can decide to start replication at the confirmed_flush_lsn. That makes sense because the client knows more about its behavior and configuration, and whether that's a safe choice or not. The only difference is whether the server is safe-by-default with intuitive semantics that match the documentation, or unsafe-by-default with unexpected semantics that don't match the documentation. Regards, Jeff Davis