> On Feb 24, 2019, at 13:44, Stephen Frost <sfrost@snowman.net> wrote:
>
> Right, and PG12 will be out for another *5* years beyond that, meaning
> people will have had 8.5 years to move from the exclusive API to the
> non-exclusive one.
The thing is that for 90% of installations, the clock will start ticking when the deprecation. Until then, most of
themare not going to feel any pressure to make the change. Most installations have a lot of other things on their
minds. They have the option of not upgrading, and that will be the option a lot of them take.
> Every one of the exclusive backups that was taken wasn't *safe*, and a
> crash during any of them (which we've certainly heard plenty about
> through various support channels over the years...) would have resulted
> in a failure to properly restart.
Most installations don't routinely encounter this. I know it happens, and it is definitely a problem, but the field is
notstrewn with corpses here. The new interface is unquestionably an improvement, but let's not get our messaging amped
upto the point that it hurts our credibility.
> No, I'm not saying that such backups are corrupted, *that* is an
> overstatement, but it isn't actually what I'm saying, just a strawman
> you've come up with to argue against.
That may not be what you are saying, but statements like "it *is* impossible to do safe backups with the existing API"
willbe heard that way. Let's keep the messaging we give users accurate.
> this isn't any different in that regard and I don't have
> sympathy for people who insist on saying that *this*, just *this* one
> API of *all* the ones we have simply *can't* be changed *ever*.
Sure, we can change anything. It's whether this particular deprecation is a good idea.
> I'm not following here, at all... We're actually better, historically,
> about not changing SQL-level constructs than C-level APIs
That's my point. Calling this an "API" makes the change sound more routine than it is. It's an "API" that a *lot* of
installationsdepend on.
> I don't agree that simply documenting the issues with
> it is a sufficient solution to make us keep it.
Understood, but I think we need to document it no matter what.
--
-- Christophe Pettus
xof@thebuild.com