Re: RelationBuildDesc Notice (corrupt DB?) - Mailing list pgsql-general

From Tony Harper
Subject Re: RelationBuildDesc Notice (corrupt DB?)
Date
Msg-id b6u96n$v9h$1@news.hub.org
Whole thread Raw
In response to RelationBuildDesc Notice (corrupt DB?)  ("Tony Harper" <trharper5@yahoo.com>)
List pgsql-general
Thanks Tom for the suggestion

>>I frankly suspect hardware problems.  You should try some testing with
>>memtest86 and badblocks to see if they turn up anything in the way of
>>flaky RAM or disk drive respectively.



"Tony Harper" <trharper5@yahoo.com> wrote in message
news:b6ia3h$1prr$1@news.hub.org...
> Tom,
> I got your e-mail, but when I try to reply, it gets returned as spam...I
> tried from my two e-mail domains (personal and business) with no success.
> Here is my response to your mail
>
>
> From the select version statement, I get the following:
>
> Postgresql 7.2.3 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2
> 20020903  (Red Hat Linux 8.0 3.2-7)
>
> And its running on an intel 933 MHz, with about 384 MB RAM
>
> As far as reproducible....I'll go into more detail and see what you think.
>
> The first time, the database had been up for about two weeks and it had
> three tables (artists, albums, tracks) to support a sourceforge
application
> (emptytree-seedy).  That application creates the db etc.  Basically the
> application auto-rips CDs to MP3 as you place them in the CD-ROM drive,
and
> it goes out to FREEDB to populate the three tables I mentioned beforehand.
> One evening the application appeared to hang, so I stopped everything,
then
> rebooted, and when I restarted everything, I got messages about
pg_statistic
> missing.  Googling for RelationBuildDesc, pg_statistic etc. and not
finding
> anything that resembled a fix, I gave up on restoring that database after
a
> few days.   I had ripped about 400 CDs at that point.  Luckily at around
300
> CDs, I had made an ODBC link and did a quick copy of the contents of those
> three tables to another database (MS Access on a Windows 2000).
>
> The following might be a bit off subject, but I want to give you the
entire
> background of the situation.  My plan to minimize redoing CDs was to have
> the application autocreate a new database, stop the app and then insert my
> retained records for the 300 CDs via ODBC, and then start the app back up
> and let the application redo the 100 CDs I was missing from the database.
> Although, I inserted the archived records into a new database
successfully,
> the application wouldn't run successfully.  After consulting with the
> designer of the sourceforge project, I began to guess that the issue was a
> sequence on the tables (used for unique row ids in each table) and when I
> was updating the table manually, the internal sequence number wasn't aware
> of the that and when I started the application again to start inserting
new
> CD information, it developed conflicts with some existing IDs (this is an
> assumption on my part that the sequencing was the issue).  So my plan was
to
> basically clear tables in the new database again, insert the info for 300
> CDs, drop the sequence, and then recreate it with a high starting value.
> This is where it happened again......
>
> So in summary....the second time I got the RelationBuildDesc
> notice/pg_statistic missing was... when I took a empty database, inserted
> about 180 artists, 300 albums, and 4261 tracks, dropped the sequence,
> created the same sequence with a high starting value.  After recreating
the
> sequence successfully, I wanted to stop the postmaster and reboot, so I
> issued a pg_ctl -D thedirectory stop    Usually this happened pretty fast,
> but this time it took about 30-45 seconds.  I then rebooted.  When I tried
a
> pg_ctl start I got the errors that I posted.
>
> The first time I got the error, I thought perhaps the application had
caused
> it, but the second time it happened, the application wasn't running at
all,
> I had just inserted some records, dropped and then recreated the sequence
> and rebooted.   I've looked at the logs, but they only echoed the errors
> sent to the screen.   There might be something discernable to you though.
>
> I've included the sql for table and sequence creation, its pretty
> simple....I don't think there is anything harmful there......?
>
> Any advice that you can provide would be most helpful.  If I've left out
> details you need, please let me know.
>
> Thanks,
>
> TRH
>
> CREATE SEQUENCE ioid_seq;
>
> CREATE TABLE artists (
>
> ioid INT4 DEFAULT nextval('ioid_seq'),
>
> title TEXT,
>
> play_date DATETIME);
>
> CREATE TABLE albums (
>
> ioid INT4 DEFAULT nextval('ioid_seq'),
>
> title TEXT,
>
> artist_ioid INT4,
>
> cddb_id TEXT,
>
> category TEXT,
>
> track_count INT4,
>
> running_time FLOAT,
>
> play_count INT4 DEFAULT 0,
>
> play_date DATETIME);
>
> CREATE TABLE tracks (
>
> ioid INT4 DEFAULT nextval('ioid_seq'),
>
> title TEXT,
>
> index INT4,
>
> album_ioid INT4,
>
> lba INT4,
>
> data INT4,
>
> duration FLOAT,
>
> play_count INT4 DEFAULT 0,
>
> play_date DATETIME);
>
> CREATE TABLE lists (
>
> ioid INT4 DEFAULT nextval('ioid_seq'),
>
> title TEXT,
>
> track_ioids INT4[]);
>
> CREATE TABLE version (name TEXT);
>
> CREATE UNIQUE INDEX track_ioid ON tracks (ioid);
>
> CREATE UNIQUE INDEX track_album_ioid_index ON tracks (album_ioid, index);
>
> CREATE UNIQUE INDEX artist_ioid ON artists (ioid);
>
> CREATE UNIQUE INDEX artist_title ON artists (title);
>
> CREATE UNIQUE INDEX album_ioid ON albums (ioid);
>
> CREATE UNIQUE INDEX list_ioid ON lists (ioid);
>
> INSERT INTO version (name) VALUES ('1.6.0.1');
>
>
> "Tony Harper" <trharper5@yahoo.com> wrote in message
> news:b6hb2u$193v$1@news.hub.org...
> > DB appears to be corrupted but cannot isolate cause, it has happened
> > multiple times after recreating database.  The system seems stable
> otherwise
> >
> > The message when trying to do
> > psql name_of_database:
> > NOTICE: RelationBuildDesc: can't open pg_statistic:  No such file or
> > directory
> > ERROR: cannot open pg_statistic:  No such file or directory
> >
> > if I do a \d
> > The message is:
> > cannot open pg_statistic:  No such file or directory
> >
> > if I do a verbose vacuum, things go fine till the end....a sample:
> > NOTICE: RelationBuildDesc: can't open pg_group:  No such file or
directory
> > NOTICE: RelationBuildDesc: can't open pg_group_name_index:  No such file
> or
> > directory
> > NOTICE: RelationBuildDesc: can't open pg_group_sysid_index:  No such
file
> or
> > directory
> > Error: _mdfd_getreInfd:  cannot open relation pg_group:  No such file or
> > director
> >
> > if I do a REINDEX from a backend:
> > NOTICE: RelationBuildDesc: can't open pg_group:  No such file or
directory
> > NOTICE: RelationBuildDesc: can't open pg_inherits:  No such file or
> > directory
> > NOTICE: RelationBuildDesc: can't open pg_inherits_rlid_seqno_index:  No
> such
> > file or directory
> >
> >
> > Anyone know what the real issue is or how to fix?
> >
> > Thanks,
> >
> > TRH
> >
> >
>
>



pgsql-general by date:

Previous
From: Marc@news.hub.org, G.Fournier@news.hub.org, From@news.hub.org:
Date:
Subject: Re: The mail nttp gateway is still broken
Next
From: "Ramesh PAtel "
Date:
Subject: Problem about Triggers and Function