2022年2月9日(水) 11:21 Michael Paquier <mich...@paquier.xyz>: > > On Tue, Feb 08, 2022 at 11:26:41AM -0500, Robert Haas wrote: > > From that point of view, there's no downside to removing from the > > server the old syntax for BASE_BACKUP and the old protocol for taking > > backups. We can't remove anything from pg_basebackup, because it is > > our practice to make new versions of pg_basebackup work with old > > versions of the server. But the reverse is not true: an older > > pg_basebackup will categorically refuse to work with a newer server > > version. Therefore keeping the code for this stuff around in the > > server has no value ... unless there is out-of-core code that (a) uses > > the BASE_BACKUP command and (b) wouldn't immediately adopt the new > > syntax and protocol anyway. If there is, we might want to keep the > > backward-compatibility code around in the server for a few releases. > > If not, we should probably nuke that code to simplify things and > > reduce the maintenance burden. > > This line of arguments looks sensible from here, so +1 for this > cleanup in the backend as of 15~. I am not sure if we should worry > about out-of-core tools that use replication commands, either, and the > new grammar is easy to adapt to.
FWIW the out-of-core utility I have some involvement in and which uses base backup functionality, uses this by executing pg_basebackup, so no problem there. But even if it used the replication protocol directly, it'd just be a case of adding another bit of Pg version-specific code handling; I certainly wouldn't expect core to hold itself back for my convenience. Regards Ian Barwick -- EnterpriseDB: https://www.enterprisedb.com
