> On Feb 24, 2019, at 14:19, Stephen Frost <sfrost@snowman.net> wrote:
> You say above that the new interface is unquestionably an improvement
> and here say that we shouldn't deprecate the old one in favor of it
> (even though we actually already have... but that's beside the point I'm
> trying to make here), so what you're advocating for is that we keep an
> old and known broken interface that we know causes real issues even
> after we've developed a new and unquestionably better one.
Yes, I am advocating exactly that. The reason that I think we need to keep the old one (or, at least, not remove it as
soonas 12) is that creating an obstacle to upgrades is worse than retaining the old one, and it *will* be an obstacle
toupgrades (or to using the community edition at all).
I do think we need a simple, pg_basebackup-level-complexity hot backup tool that allows a forked copy operation, per
Andres'suggestion.
There's no single answer to every possible situation like this that pops up; it depends on how widely used the
interfacewas, how reasonable the expectation of permanence is, and the difficulty the users will encounter in changing
tothe new one, along with the complexity of maintaining the documentation and code for the old interface.
> A lot of them depended on pg_wal being named pg_xlog too, but we seem to
> have managed reasonably well through that, not to mention all the
> catalog changes that caused issues for monitoring, etc.
Some of the incompatible catalog changes (in particular, in pg_stat_activity) I thought were gratuitous, but we did
them,and no point in relitigating that now. I'd say that the internal layout of PGDATA is fairly weak promise compared
toan SQL-level construct, especially one as widely used as pg_start_backup().
--
-- Christophe Pettus
xof@thebuild.com