On Tuesday, September 3, 2024, raf <
postgres@raf.org> wrote:
Hi,
I need help!
I'm upgrading an ancient (but still awesome) postgresql-9.6.24 (via EnterpriseDB)
to (a no doubt even more awesome) postgresql-15.8 (via debian (stable) packages)
but am unable to load database backups that were encrypted via gpg. Loading from
unencrypted backups works fine (and the millions of tests all pass! Yay!).
I have a convenience program for handling loading called "load"
and the underlying commands that it executes look like this:
dropdb -h payroll -p 5433 -U postgres payroll_tst
createdb -h payroll -p 5433 -U postgres -T template0 -E utf8 -O admin payroll_tst
Given the following command
gpg --decrypt 20240904-011254-payroll_tst.pgdump.gpg.aps24 | pg_restore -1 -h payroll -p 5433 -U postgres -d payroll_tst -Fc
And this error
pg_restore: [archiver (db)] could not execute query: ERROR: could not find function "xml_is_well_formed" in file "/usr/lib/postgresql/15/lib/pgxml.so"
Command was: CREATE FUNCTION public.xml_is_well_formed(text) RETURNS boolean
LANGUAGE c IMMUTABLE STRICT
AS '$libdir/pgxml', 'xml...
This should be expected. In particular…
gpg: error writing to '-': Broken pipe
gpg: error flushing '[stdout]': Broken pipe
gpg: handle plaintext failed: Broken pipe
pgrestore encountered errors
I'm not worried about the xml_is_well_formed error (or the xml_valid error that
would happen next). I think those functions are ancient and irrelevant and not
in use, and I'm happy for pg_restore to continue, like it does when gpg is not
involved.
You specified “-1” so I don’t get why you believe pg_restore should be continuing to execute in the face of the SQL error.
David J.
