Thread
-
Recovering data from binary files?
Paulo Jan <admin@digital.ddnet.es> — 2000-05-08T14:59:37Z
Hi all: Well, after my earlier post regarding pg_operator being corrupted, I received a mail from one of the Postgres developers (I think) talking about one of the system indexes (pg_attribute_relid_attnum_index) being corrupted, so I gave it a try and copied said file from the template1 database to the one I have to recover... and now it gives me another error: "cannot find attribute 1 of relation pg_user". Like before, I can't even do a \d to see the existing tables in the database, much less insert/update anything in the pg_* tables to fix it, and after struggling the whole morning with it, I have pretty much given up on that path. I am trying now to: 1) Re-create the database in another machine. 2) Copy the binary files that contain the tables (minus the pg_* ones) to the other server, in the place where the new database has been created ($PGDATA/base/$dbname). 3) Try to access the tables from there using psql. The problem now is that, although I can view the tables correctly, they all come up as empty. All the SELECTs I try on them return nothing. And the strange thing is that pg_class.reltuples says that said table has 5478 tuples, which is correct. Any other ideas? Is there any other way to access the binary files and extract the information in them to text? My manager is starting to talk about migrating to SQL Server, and frankly, at this point I'm finding less and less arguments to counter him... Paulo Jan. DDnet.
-
RE: Recovering data from binary files?
Hiroshi Inoue <inoue@tpf.co.jp> — 2000-05-08T15:47:38Z
> -----Original Message----- > From: pgsql-general-owner@hub.org > [mailto:pgsql-general-owner@hub.org]On Behalf Of Paulo Jan > Sent: Tuesday, May 09, 2000 12:00 AM > To: pgsql-general@postgresql.org > Cc: fvilches@mail.ddnet.es > Subject: [GENERAL] Recovering data from binary files? > > > Hi all: > > Well, after my earlier post regarding pg_operator being corrupted, I > received a mail from one of the Postgres developers (I think) talking > about one of the system indexes (pg_attribute_relid_attnum_index) being > corrupted, so I gave it a try and copied said file from the template1 > database to the one I have to recover... and now it gives me another > error: "cannot find attribute 1 of relation pg_user". Like before, I > can't even do a \d to see the existing tables in the database, much less > insert/update anything in the pg_* tables to fix it, and after > struggling the whole morning with it, I have pretty much given up on > that path. > I am trying now to: > > 1) Re-create the database in another machine. > 2) Copy the binary files that contain the tables (minus the > pg_* ones) > to the other server, in the place where the new database has been > created ($PGDATA/base/$dbname). Oh it seems almost same as pg_upgrade. However you should probably copy pg_log and pg_variable to $PGDATA as pg_upgrade does. In addtion if postmaster is running,you should shutdown before processing 2). Regards. Hiroshi Inoue Inoue@tpf.co.jp > 3) Try to access the tables from there using psql. > > The problem now is that, although I can view the tables > correctly, they > all come up as empty. All the SELECTs I try on them return nothing. And > the strange thing is that pg_class.reltuples says that said table has > 5478 tuples, which is correct. > Any other ideas? Is there any other way to access the > binary files and > extract the information in them to text? My manager is starting to talk > about migrating to SQL Server, and frankly, at this point I'm finding > less and less arguments to counter him... > > > Paulo Jan. > DDnet. >
-
Miracle
Paulo Jan <admin@digital.ddnet.es> — 2000-05-08T17:05:09Z
> > Oh it seems almost same as pg_upgrade. > However you should probably copy pg_log and pg_variable to > $PGDATA as pg_upgrade does. > In addtion if postmaster is running,you should shutdown before > processing 2). > > Regards. > Well. It worked!!! The database was succesfully recovered. Thanks a lot. Paulo Jan. DDnet.
-
7.0 RPM?
J. Atwood <jatwood@bwanazulia.com> — 2000-05-09T22:52:39Z
I have been looking around for the RPM for 7.0 anyone have a quick link? Thanks, J
-
Re: 7.0 RPM?
Karl DeBisschop <kdebisschop@h00a0cc3b7988.ne.mediaone.net> — 2000-05-10T02:25:31Z
"J. Atwood" wrote: > I have been looking around for the RPM for 7.0 anyone have a quick link? > > Thanks, > J not in any way official, but I did a cheap knock off of the 7.0RC1 rpms. You should be able to pick them up at karl.debisschop.net/src/postgres/ These are based on RPMs by Lamar Owen at http://www.ramifordistat.net/postgres/beta/SRPMS - I've really added nothing (though I expect to have build of the plperl procedural language by tomorrow). In fact I'd guess that the reason I can post this before Lamar is because he is trying to improve the existing RPMS, whereas I just wanted to start running 7.0 on some development machines as soon as possible. Testing is limited, but I've deployed this successfully. He has SRPMs for RC5 at his site, but not the final yet. If you do use these. plan on upgrading once Lamar releases his final. But you should be able to do that without a dump/restore cycle, which was my prime concern. Karl DeBisschop
-
Re: 7.0 RPM?
Tom Lane <tgl@sss.pgh.pa.us> — 2000-05-10T04:31:03Z
Karl DeBisschop <kdebisschop@h00a0cc3b7988.ne.mediaone.net> writes: > If you do use these. plan on upgrading once Lamar releases his final. But > you should be able to do that without a dump/restore cycle, which was my > prime concern. 7.0RC5 is database-compatible with the final, earlier betas are *not*. You can use pg_upgrade to update from any 6.5-or-later version if you are feeling adventurous, but I'd definitely suggest making a backup first in case things go wrong and you have to initdb and restore. regards, tom lane
-
Re: 7.0 RPM?
Karl DeBisschop <kdebisschop@range.infoplease.com> — 2000-05-10T13:21:12Z
Tom Lane wrote: > Karl DeBisschop <kdebisschop@h00a0cc3b7988.ne.mediaone.net> writes: > > If you do use these. plan on upgrading once Lamar releases his final. But > > you should be able to do that without a dump/restore cycle, which was my > > prime concern. > > 7.0RC5 is database-compatible with the final, earlier betas are *not*. > You can use pg_upgrade to update from any 6.5-or-later version if you > are feeling adventurous, but I'd definitely suggest making a backup > first in case things go wrong and you have to initdb and restore. > > regards, tom lane Sorry if I was not clear. The RPMs I prepared use Lamar Owen spec from RC1, but use final release sources. Upgrading from final release to final release should not be a problem, I think. I only recommended it because I understand from his recent posts sthat Lamar has many inprovements to the RPM install script that I have not taken advantage of. Karl
-
Re: 7.0 RPM?
Thomas Lockhart <lockhart@alumni.caltech.edu> — 2000-05-10T13:39:35Z
> > 7.0RC5 is database-compatible with the final, earlier betas are *not*. > > You can use pg_upgrade to update from any 6.5-or-later version if you > > are feeling adventurous, but I'd definitely suggest making a backup > > first in case things go wrong and you have to initdb and restore. > Sorry if I was not clear. The RPMs I prepared use Lamar Owen spec from RC1, > but use final release sources. Upgrading from final release to final release > should not be a problem, I think. I only recommended it because I understand > from his recent posts sthat Lamar has many inprovements to the RPM install > script that I have not taken advantage of. Tom's point is that RC5 is *not* database-compatible with previous release candidates due to a last minute bug fix in the location of group table indices. So anything earlier than RC5 needs (at least) a pg_upgrade, and (for me) preferably a full dump/initdb/restore cycle. - Thomas -- Thomas Lockhart lockhart@alumni.caltech.edu South Pasadena, California -
Re: 7.0 RPM?
Karl DeBisschop <kdebisschop@range.infoplease.com> — 2000-05-10T14:14:14Z
Thomas Lockhart wrote: > > > 7.0RC5 is database-compatible with the final, earlier betas are *not*. > > > You can use pg_upgrade to update from any 6.5-or-later version if you > > > are feeling adventurous, but I'd definitely suggest making a backup > > > first in case things go wrong and you have to initdb and restore. > > Sorry if I was not clear. The RPMs I prepared use Lamar Owen spec from RC1, > > but use final release sources. Upgrading from final release to final release > > should not be a problem, I think. I only recommended it because I understand > > from his recent posts sthat Lamar has many inprovements to the RPM install > > script that I have not taken advantage of. > > Tom's point is that RC5 is *not* database-compatible with previous > release candidates due to a last minute bug fix in the location of > group table indices. > > So anything earlier than RC5 needs (at least) a pg_upgrade, and (for > me) preferably a full dump/initdb/restore cycle. > > - Thomas > > -- > Thomas Lockhart lockhart@alumni.caltech.edu > South Pasadena, California My point is that my RPMS use the final release sources Karl
-
Re: 7.0 RPM?
Thomas Lockhart <lockhart@alumni.caltech.edu> — 2000-05-10T14:27:07Z
> My point is that my RPMS use the final release sources Doh! Sorry, I was focused on the RC1 thing... -- Thomas Lockhart lockhart@alumni.caltech.edu South Pasadena, California
-
Re: 7.0 RPM?
Lamar Owen <lamar.owen@wgcr.org> — 2000-05-10T20:25:07Z
"J. Atwood" wrote: > > I have been looking around for the RPM for 7.0 anyone have a quick link? An announcement will be made shortly. Shortly being within a day or two -- possibly tonight. More likely tomorrow night. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11