The easiest way to perform a base backup is to use the pg_basebackup tool. While pg_basebackup will receive some new improvements in PostgreSQL 15, the low-level API still offers more flexibility.
The exclusive backup mode was deprecated since PostgreSQL 9.6 when non-exclusive backups were introduced. PostgreSQL 15 finally removes that long-deprecated feature and, to avoid any confusion, renames the pg_start_backup()and pg_stop_backup()functions to pg_backup_start()and pg_backup_stop(). pg_backup_start_time()and pg_is_in_backup()functions will also be removed because they were focused on exclusive backups.
What's the issue with exclusive backups?
The biggest issue is when the database server stops abruptly while in this mode: the server could fail to start afterward.
The exclusive backup mode creates a backup_label file in the data directory, containing the location of the checkpoint starting the backup. This makes sure that during startup, PostgreSQL does not recover from the latest checkpoint registered in pg_control. Doing so would cause data corruption, since the backup may contain data files from before that checkpoint.
Without providing a restore_command, PostgreSQL would have to use the transaction logs from the local pg_wal directory. If there has been enough activity, the WAL segment containing the starting checkpoint may already have been archived and recycled. The startup process would then fail and you would have to manually remove the backup_label file left behind from the failed backup to be able to restart PostgreSQL.
Furthermore, restoring a backup without the correct backup_label file would most of the time lead to data corruption. So, with the exclusive backup mode, it is not possible to make the difference between a server that crashed while a backup is taken and a cluster restored from a backup: ending in user confusion, problems to start PostgreSQL, and ultimately even data loss.
How does the non-exclusive backup mode work?
The non-exclusive backup mode works in such a way that the backup_label file and the tablespace map are not created in the data directory but are returned by pg_backup_stop. In this case, the backup tool will have to write both files with the backup taken.
This has the advantage to leverage all the problems induced by the exclusive backup mode but requires a continuous database connection during the backup: if the client disconnects while the backup is taken, it is aborted.
Conclusion
The non-exclusive backup mode was introduced 6 years ago and has been used in most of the backup tools available in the community (e.g. Barman, pgBackRest, etc) since then. The latest releases of those tools already support PostgreSQL 15 so this change shouldn't affect their users.
However, users having their own homemade backup script (e.g. using pre/post-backup hooks and VM snapshots) will need to pay extra attention to the compatibility of those scripts with this new release.