Thread: BUG #5624: Getting error while taking the backup of database from remote machine

The following bug has been logged online:

Bug reference:      5624
Logged by:          Priya Kaliappan
Email address:      priya_kaliappan@infosys.com
PostgreSQL version: 8.3.0.112
Operating system:   Red Hat Enterprise Linux Server release 5.5 (Tikanga)
Description:        Getting error while taking the backup of database from
remote machine
Details:

Our source machine set up :  Enterprisedb 8.3 version(64 bit) Remote machine
: RHEL 8.1 version (64 bit).

We are in a need to take a dump of the database sitting in remote machine
from the source machine that too both postgres db are not in same version.
we are encountering the below error while trying from source machine:

$pg_dump -U postgres -h (ip) -d db_name
Password:

pg_dump: SQL command failed
pg_dump: Error message from server: ERROR:  column "nspparent" does not
exist
pg_dump: The command was: SELECT tableoid, oid, nspname, (SELECT rolname
FROM pg  _catalog.pg_roles WHERE oid = nspowner) as rolname, nspacl,
nspparent FROM pg_namespace WHERE nspparent = 0

Please provide us a solution on how to backup database residing on remote
machine.


Thanks,
Priya

"Priya Kaliappan" <priya_kaliappan@infosys.com> writes:
> Our source machine set up :  Enterprisedb 8.3 version(64 bit) Remote machine
> : RHEL 8.1 version (64 bit).

> $pg_dump -U postgres -h (ip) -d db_name
> Password:

> pg_dump: SQL command failed
> pg_dump: Error message from server: ERROR:  column "nspparent" does not
> exist
> pg_dump: The command was: SELECT tableoid, oid, nspname, (SELECT rolname
> FROM pg  _catalog.pg_roles WHERE oid = nspowner) as rolname, nspacl,
> nspparent FROM pg_namespace WHERE nspparent = 0

You should probably be asking EDB for support on this, not the PG
community.  I will just note that there is not, and never has been,
any pg_namespace.nspparent column in any community release ... so this
is evidently an EDB-custom version of pg_dump, and it's not compatible
with the server you're pointing it at.

            regards, tom lane