`pg_restore` error: must be owner of extension plpgsql

[babaee74]

Bug Report

dbbackup.db.exceptions.CommandConnectorError: Error running: pg_restore --dbname=postgresql://adminnn:[email protected]:5432/apiusersdb --single-transaction --clean pg_restore: [custom archiver] WARNING: ftell mismatch with expected position -- ftell used pg_restore: [archiver (db)] Error while PROCESSING TOC: pg_restore: [archiver (db)] Error from TOC entry 1; 3079 13039 EXTENSION plpgsql pg_restore: [archiver (db)] could not execute query: ERROR: must be owner of extension plpgsql Command was: DROP EXTENSION plpgsql;

Describe the bug

I did backup using this command: python3 manage.py dbbackup --compress and i got this file: default-robo-server-2023-11-09-202002.psql.bin.gz

then i tried to restore it using the command below: python3 manage.py dbrestore --uncompress -I /home/esi/dbbackup/default-robo-server-2023-11-09-202002.psql.bin.gz --traceback and i got the error below: dbbackup.db.exceptions.CommandConnectorError: Error running: pg_restore --dbname=postgresql://adminnn:[email protected]:5432/apiusersdb --single-transaction --clean pg_restore: [custom archiver] WARNING: ftell mismatch with expected position -- ftell used pg_restore: [archiver (db)] Error while PROCESSING TOC: pg_restore: [archiver (db)] Error from TOC entry 1; 3079 13039 EXTENSION plpgsql pg_restore: [archiver (db)] could not execute query: ERROR: must be owner of extension plpgsql Command was: DROP EXTENSION plpgsql;

I also did use -c to decrypt despite not using it when I was doing backup and it did not work

To Reproduce

Steps to reproduce the behavior

Expected behavior

the dtaabase has been restored

Versions

Django-dbbackup

django 3.2.4 django-dbbackup==4.0.2

External tools

• Python 3.9.10
• ubuntu 20.04

[Archmonger]

@babaee74 Can you verify if adding --pg-options '--no-owner' to your dbrestore command fixes this?

If not, then I will need to create a solution that automatically removes plpgsql related statements from the dump.

The issue appears to be that cloud-hosted Postgres doesn't give "real superuser" permissions to admin accounts, so plpgsql can't be created/destroyed due to permissions. If --no-owner doesn't work, then the solution would involve dbbackup automatically removing plpgsql related SQL statements from the dump.