Thread: Problem do backup/restore for empty database
Hello, I tried to do backup/restore of empty database. And get the following error: Connecting to database for restore Connecting to test4 as postgres Creating OPERATOR = Archiver(db): Could not execute query. Code = 7. Explanation from backend: 'ERROR: OperatorDef: operator "=" already defined '. Another funny thing is that dump of empty database occupies 657614 bytes. It is quite much... -- Sincerely Yours, Denis Perchine ---------------------------------- E-Mail: dyp@perchine.com HomePage: http://www.perchine.com/dyp/ FidoNet: 2:5000/120.5 ----------------------------------
At 18:13 21/10/00 +0700, Denis Perchine wrote: > >I tried to do backup/restore of empty database. >And get the following error: > >Archiver(db): Could not execute query. Code = 7. Explanation from backend: >'ERROR: OperatorDef: operator "=" already defined >'. > >Another funny thing is that dump of empty database occupies 657614 bytes. >It is quite much... > Works fine for me. What command are you using? What does pg_restore archive-file-name produce? Have you done anything nasty to template1? ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.B.N. 75 008 659 498) | /(@) ______---_ Tel: (+61) 0500 83 82 81 | _________ \ Fax: (+61) 0500 83 82 82 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
> >I tried to do backup/restore of empty database. > >And get the following error: > > > >Archiver(db): Could not execute query. Code = 7. Explanation from backend: > >'ERROR: OperatorDef: operator "=" already defined > >'. > > > >Another funny thing is that dump of empty database occupies 657614 bytes. > >It is quite much... > > Works fine for me. What command are you using? What does pg_dump --blob -Fc test3 -f test3.tar -v pg_restore test3.tar --db=test4 -v > pg_restore archive-file-name pg_restore test3.tar produces 688634 bytes length. pg_restore -l test3.tar produces long list. Here there are some first lines: ; ; Archive created at Sat Oct 21 18:05:33 2000 ; dbname: test3 ; TOC Entries: 2899 ; Compression: -1 ; Dump Version: 1.4-17 ; Format: CUSTOM ; ; ; Selected TOC Entries: ; 2338; 15 OPERATOR = postgres > produce? > > Have you done anything nasty to template1? Just initdb. -- Sincerely Yours, Denis Perchine ---------------------------------- E-Mail: dyp@perchine.com HomePage: http://www.perchine.com/dyp/ FidoNet: 2:5000/120.5 ----------------------------------
At 18:33 21/10/00 +0700, Denis Perchine wrote: > >; >; Archive created at Sat Oct 21 18:05:33 2000 >; dbname: test3 >; TOC Entries: 2899 >; Compression: -1 >; Dump Version: 1.4-17 >; Format: CUSTOM >; >; >; Selected TOC Entries: >; >2338; 15 OPERATOR = postgres > OK. I just built with absolute latest CVS again, and pg_dump has started dumping the entire schema, including system tables, functions etc. Looks like the way it decides something is user-defined is now broken. Same is true for non-empty databases. ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.B.N. 75 008 659 498) | /(@) ______---_ Tel: (+61) 0500 83 82 81 | _________ \ Fax: (+61) 0500 83 82 82 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
BTW, also, if it is possible it is a good idea to remove the following warning if there are no BLOBs in the archive: Archiver: WARNING - skipping BLOB restoration -- Sincerely Yours, Denis Perchine ---------------------------------- E-Mail: dyp@perchine.com HomePage: http://www.perchine.com/dyp/ FidoNet: 2:5000/120.5 ----------------------------------
At 22:33 21/10/00 +1000, Philip Warner wrote: > >OK. I just built with absolute latest CVS again, and pg_dump has started >dumping the entire schema, including system tables, functions etc. Looks >like the way it decides something is user-defined is now broken. > >Same is true for non-empty databases. > Looks like the problem is the way pg_dump determines the last builtin OID. Currently, the code executes: SELECT oid from pg_database where datname = 'template1'; which in CVS version on my machine, produces '1'. This is clearly a problem. Does anyone have a suggestion on the best way to get the last builtin OID? Or should the OID of template1 be larger??? ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.B.N. 75 008 659 498) | /(@) ______---_ Tel: (+61) 0500 83 82 81 | _________ \ Fax: (+61) 0500 83 82 82 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
At 18:33 21/10/00 +0700, Denis Perchine wrote: > >pg_dump --blob -Fc test3 -f test3.tar -v >pg_restore test3.tar --db=test4 -v > Should work with current CVS sources now... ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.B.N. 75 008 659 498) | /(@) ______---_ Tel: (+61) 0500 83 82 81 | _________ \ Fax: (+61) 0500 83 82 82 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/