Hi Carsten, I had the same problems as Joop, here, too, the psql -q helped.
See this post for another one who had the problem. Strangely enough I could not find any hint in the bacula community repositories. Why does it take so long (over a year) Regards, Sebastian On Tue, 02 Sep 2025 18:03:07 +0200 Carsten Leonhardt <[email protected]> wrote: > Control: unmerge -1 > Control: reopen -1 > > Hi Joop, > > actually, we fixed the escaping, but this is the first time we hear > about the "-q" parameter problem. > > We'll need to investigate that. > > Regards > > Carsten > > > Carsten Leonhardt <[email protected]> writes: > > > Control: forcemerge 1108272 -1 > > > > Hi Joop, > > > > thanks for your report. We have already addressed this in version > > 15.0.3-4, which unfortunately is not in the current Debian stable > > release (c.f. bug #1108272). > > > > We highly recommend letting dbconfig-common handle the databases. > > > > Regards > > > > Carsten > > > > > > Joop Boonen <[email protected]> writes: > > > >> Package: bacula-director-pgsql > >> > >> Version: 15.0.3-3 > >> > >> When I invoke > >> > >> sudo -u postgres /usr/share/bacula-director/update_postgresql_tables -d <bacula_database> > >> The Baculadatabase isnt' upgraded due to a few "errors" in the script. > >> > >> > >> > >> The First error the psql dump is created without a -q, this causes that header data ends up in the file. Because of this the restore fails. > >> > >> > >> > >> Secondly the postgresql do $$ is not correctly escaped. Therefore bash replaces the $$ to the current process id. > >> > >> > >> > >> > >> > >> > >> > >> > >> I suggest the following patch: > >>
