Hi, On 2019-02-24 14:35:04 -0800, Christophe Pettus wrote: > > On Feb 24, 2019, at 14:19, Stephen Frost <sfr...@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 soon as 12) is that > creating an obstacle to upgrades is worse than retaining the old one, > and it *will* be an obstacle to upgrades (or to using the community > edition at all).
It sounds to me like you treat this as if having the old method around had no downsides. But I have seen *numereous* downtimes due to it, and also corruption triggered by it (people following the hint to remove backup_label). > > 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 to an SQL-level construct, > especially one as widely used as pg_start_backup(). I don't buy that, because you normally specifically should exclude pg_xlog/pg_wal from basebackups. Greetings, Andres Freund
