Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 6B5116500EA for ; Wed, 19 Nov 2008 18:49:04 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 99528-05 for ; Wed, 19 Nov 2008 18:48:59 -0400 (AST) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mail.postgresql.org (Postfix) with ESMTP id 440DD650004 for ; Wed, 19 Nov 2008 18:48:58 -0400 (AST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1L2vqt-0005bP-Ki for pgsql-admin@postgresql.org; Wed, 19 Nov 2008 22:48:51 +0000 Received: from 77.70.61.39 ([77.70.61.39]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Nov 2008 22:48:51 +0000 Received: from milen by 77.70.61.39 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Nov 2008 22:48:51 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: pgsql-admin@postgresql.org From: "Milen A. Radev" Subject: Re: Problems With pg_dumpall and OIDs Date: Thu, 20 Nov 2008 00:48:43 +0200 Lines: 18 Message-ID: References: <623884546.38971227134154902.JavaMail.root@mail-01.cse.ucsc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 77.70.61.39 User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) In-Reply-To: <623884546.38971227134154902.JavaMail.root@mail-01.cse.ucsc.edu> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=1.599 tagged_above=0 required=5 tests=RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.599 X-Spam-Level: * X-Archive-Number: 200811/119 X-Sequence-Number: 30773 Tim Gustafson написа: > Hello, > > I currently have a old GForge installation running on Postgres 7.4.19. GForge relies on the OID columns of their application tables for different things. I'm trying to upgrade Postgres to 8.2, and in order to do so, I'm doing: > > pg_dumpall --oids --clean > foo.sql > > However, the "CREATE TABLE" statements in foo.sql don't have "WITH OIDS" specified, so when the tables are created in the new server, they are not getting OID columns, and then the data load portion of the SQL script appears to essentially be ignoring the OID information. > > Is there an updated pg_dumpall that fixes this problem? Was this a known issue in the 7.4.19 pg_dumpall that was fixed? Any suggestions on how best to get the data out of the 7.4 server and in to the 8.2 server while maintaining all the OID information? [...] A workaround: temporarily turn to "on" the value off the "default_with_oids" parameter in your configuration file (the defaults is "off"). -- Milen A. Radev