Re: pg_dump problems: [archiver (db)] query failed: ERROR: relation"pg_opfamily" does not exist - Mailing list pgsql-general
From | Adrian Klaver |
---|---|
Subject | Re: pg_dump problems: [archiver (db)] query failed: ERROR: relation"pg_opfamily" does not exist |
Date | |
Msg-id | 52d04185-f4ac-fe44-2e97-4646be3a0fae@aklaver.com Whole thread Raw |
In response to | Re: pg_dump problems: [archiver (db)] query failed: ERROR: relation"pg_opfamily" does not exist (Erwin Moller <erwin@darwine.nl>) |
Responses |
Re: pg_dump problems: [archiver (db)] query failed: ERROR: relation"pg_opfamily" does not exist
|
List | pgsql-general |
On 8/20/19 7:37 AM, Erwin Moller wrote: > > Op 8/20/2019 om 3:32 PM schreef Adrian Klaver: >> On 8/20/19 6:18 AM, Erwin Moller wrote: >>> >>> >>> Op 8/20/2019 om 2:07 PM schreef Ian Barwick: >>>> On 8/20/19 7:12 PM, Erwin Moller wrote: >>>>> Hi, >>>>> >>>>> While trying to move an old 8.1 Postgres install to a new server >>>>> with postgres 10.10, I get an error, listed hereunder: >>>>> I am trying to get a mydump_x_x_x.sql file to use to reinstall on >>>>> the target machine. >>>>> >>>>> From my new machine I connect to my old machine like this: >>>>> erwin@ubuntu:~$ pg_dump -f "/home/erwin/mydump_$(date >>>>> +%d_%m_%Y).sql" -C -h somehost.com -p 5433 -U myvalidusername -d >>>>> myremotedb >>>>> Password: >>>>> pg_dump: [archiver (db)] query failed: ERROR: relation >>>>> "pg_opfamily" does not exist >>>>> pg_dump: [archiver (db)] query was: SELECT classid, objid, >>>>> refclassid, refobjid, deptype FROM pg_depend WHERE deptype != 'p' >>>>> AND deptype != 'e' >>>>> UNION ALL >>>>> SELECT 'pg_opfamily'::regclass AS classid, amopfamily AS objid, >>>>> refclassid, refobjid, deptype FROM pg_depend d, pg_amop o WHERE >>>>> deptype NOT IN ('p', 'e', 'i') AND classid = 'pg_amop'::regclass >>>>> AND objid = o.oid AND NOT (refclassid = 'pg_opfamily'::regclass AND >>>>> amopfamily = refobjid) >>>>> UNION ALL >>>>> SELECT 'pg_opfamily'::regclass AS classid, amprocfamily AS objid, >>>>> refclassid, refobjid, deptype FROM pg_depend d, pg_amproc p WHERE >>>>> deptype NOT IN ('p', 'e', 'i') AND classid = 'pg_amproc'::regclass >>>>> AND objid = p.oid AND NOT (refclassid = 'pg_opfamily'::regclass AND >>>>> amprocfamily = refobjid) >>>>> ORDER BY 1,2 >>>>> >>>>> And no archive is created. >>>>> >>>>> Does any of you kind people have advice? I am sure this worked on >>>>> postgres9. >>>> >>>> It looks like this was broken just before 10.10 was released, and >>>> has since been fixed; >>>> see: >>>> >>>> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=6844adba54f7d96f30f834efc6d9aa1e52e5672d >>>> >>>> >>>> Your options are: >>>> - find a 10.9 or earlier package and use the pg_dump from that >>>> - build pg_dump yourself >>>> - wait for 10.11 to come out (though I imagine that won't be for a >>>> month or two) >>>> >>>> >>>> Regards >>>> >>>> Ian Barwick >>>> >>> >>> Thanks a lot, Ian! >>> >>> That saved me an upcoming headache. I searched a lot on Google but >>> couldn't find any relevant information. >>> >>> Will installing Postgres 11 also work? (Not the Ubuntu18.04 default >>> for Postgres, but doable). >>> Or does those pg_dump versions also expect pg_opfamily to exist? >> >> >> From the bug that introduced the issue: >> >> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=07b39083c >> >> "Per bug #15934 from Tom Gottfried. Back-patch to all supported >> branches." >> >> So I'm guessing it is in the most recent release of all current versions. > > Thank you, Adrian. > > That is a bummer. > Since I have no idea how to safely install an older version of pg_dump > alongside my current 10.10 install, I will wait for the patch. A quick test showed that: 1) Go here: https://apt.postgresql.org/pub/repos/apt/pool/main/p/postgresql-11/ 2) Grab https://apt.postgresql.org/pub/repos/apt/pool/main/p/postgresql-11/postgresql-client-11_11.4-1.pgdg18.10%2b1_amd64.deb 3) Using Ark extract pg_dump from data.tar.xz at path /usr/lib/postgresql/11/bin ./pg_dump -V pg_dump (PostgreSQL) 11.4 (Ubuntu 11.4-1.pgdg18.10+1) I do not have a 8.1 instance to try against, so I could not test that part. > > Thank you for your responses! > > Regards, > Erwin Moller > > > > > -- Adrian Klaver adrian.klaver@aklaver.com
pgsql-general by date: