In June 2026, a Debian Bacula package maintainer reported a problem with the update_postgresql_tables script in the Bacula GitLab issue tracker. The issue had originally been reported in the Debian bug tracking system in September 2025.
The problem affects users who manually run update_postgresql_tables with PostgreSQL 15 or later while upgrading the Catalog schema from version 15 to version 1017, which was introduced with Bacula 11.0. This is not a bug in Debian itself, but in the upgrade script supplied by Bacula.
Bacula stores metadata about backups, files, and other resources in a database known as the Bacula Catalog. Some Bacula releases, usually major ones, introduce changes to the SQL table structure used to store this metadata. When upgrading between such releases, an upgrade script must be run to bring the Catalog schema up to the version required by the new Bacula release.
Updating the Catalog schema is one of the most important stages of a major Bacula upgrade. If the process fails, the Catalog may not be upgraded to the schema version required by the new version of Bacula.
The reported failure occurs while the script is restoring a temporary export of the File table. Status messages generated by several preceding SET commands are written to the export file along with the actual table data. When the script later attempts to restore the exported data, the unexpected lines cause the operation to fail.
In the original Debian bug report, the reporter also proposed a patch adding the -q option to the affected psql commands. This suppresses the additional status messages and prevents them from being written to the temporary export file. Initially, however, it was unclear why users had not reported the problem earlier.
A Bacula community member named Martin traced the problem to a behavioral change introduced in PostgreSQL 15. When multiple SQL commands are passed to psql in a single invocation, PostgreSQL 15 and later display status messages for all of them. Earlier versions display only the output associated with the final command.
For example, PostgreSQL versions earlier than 15 produce the following output:
$ psql -d bacula -t -c "set work_mem='1GB'; set enable_mergejoin to off; set enable_hashjoin to off; SELECT 'DO SOME EXPORT';"
DO SOME EXPORT
PostgreSQL 15 and later also display the status of each preceding SET command:
$ psql -d bacula -t -c "set work_mem='1GB'; set enable_mergejoin to off; set enable_hashjoin to off; SELECT 'DO SOME EXPORT';"
SET
SET
SET
DO SOME EXPORT
Martin suggested that the problem may have remained unnoticed because Bacula 11.0, which introduced the affected commands, predates PostgreSQL 15 by approximately two years. Many users may therefore have completed the relevant Bacula upgrade before adopting PostgreSQL 15.
On Debian systems, Catalog schema upgrades are normally handled through the dbconfig-common framework. Debian installations that allow dbconfig-common to perform the Catalog upgrade are not affected by this particular problem. It concerns users who manually run the upstream update_postgresql_tables script instead.
At the time of writing, the issue remains open in the Bacula GitLab tracker and has not yet been fixed in the upstream Bacula code. After investigating the cause of the problem, the Debian Bacula maintainers incorporated the -q change originally proposed in the Debian bug report into the Debian packaging repository. The downstream patch protects Debian users who perform the Catalog upgrade manually, outside dbconfig-common, using the script supplied by Bacula.
More information about the issue is available from the following sources:
Bacula GitLab issue:
Issue in the Bacula GitLab bug tracker
Original Debian bug report:
Bug #1113777
Explanation on the Bacula-Users mailing list:
Topic on the Bacula-Users mailing list
Patch in the Debian packaging repository:
Patch in Debian Git repository