weird problem

On Thu, 10 Jul 2003, Christopher Kings-Lynne wrote:

Just saw this on our demo server:

root@phppgadmin:~/htdocs/webdb/conf# /usr/local/pgsql-7.3.3/bin/psql -p5473
phppgadmin
psql: FATAL: cannot open segment 1 of relation
pg_trigger_tgrelid_tgname_index (target block 8310112): No such file or
directory

Seems like a hosed file system to me. You'll probably need to go to
backups and should do some hardware tests.

Which file system is this running on. There seem to be a large number of
people on IRC will similar problems when running on ReiserFS.

Gavin

On Thu, Jul 10, 2003 at 11:45:09AM +1000, Gavin Sherry wrote:

On Thu, 10 Jul 2003, Christopher Kings-Lynne wrote:

Just saw this on our demo server:

root@phppgadmin:~/htdocs/webdb/conf# /usr/local/pgsql-7.3.3/bin/psql -p5473
phppgadmin
psql: FATAL: cannot open segment 1 of relation
pg_trigger_tgrelid_tgname_index (target block 8310112): No such file or
directory

Seems like a hosed file system to me. You'll probably need to go to
backups and should do some hardware tests.

Hmm... I was thinking the index could be somehow corrupted. However,
it's strange that all databases have the same problem, since pg_trigger
is not shared across databases.

Have you tried reindexing pg_trigger?

Which file system is this running on. There seem to be a large number of
people on IRC will similar problems when running on ReiserFS.

Well, older versions of ReiserFS corrupted data for me after crashes
(not PG data though -- CUPS config files and stuff). I supposed newer
versions were fixed, and I think Cristopher runs FreeBSD anyway?

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Uno puede defenderse de los ataques; contra los elogios se esta indefenso"

Hmm... I was thinking the index could be somehow corrupted. However,
it's strange that all databases have the same problem, since pg_trigger
is not shared across databases.

Have you tried reindexing pg_trigger?

Can't - I can't log into any database.

Maybe it's one of psql's startup queries causing the problem?

Chris

On Thu, 10 Jul 2003, Christopher Kings-Lynne wrote:

Hmm... I was thinking the index could be somehow corrupted. However,
it's strange that all databases have the same problem, since pg_trigger
is not shared across databases.

Have you tried reindexing pg_trigger?

Can't - I can't log into any database.

Maybe it's one of psql's startup queries causing the problem?

Maybe, perhaps try a standalone backend (I think you'll need to give it a
-P as well). But it is wierd that it's happening on all databases.

On Wed, 2003-07-09 at 21:45, Gavin Sherry wrote:

On Thu, 10 Jul 2003, Christopher Kings-Lynne wrote:

Just saw this on our demo server:

root@phppgadmin:~/htdocs/webdb/conf# /usr/local/pgsql-7.3.3/bin/psql -p5473
phppgadmin
psql: FATAL: cannot open segment 1 of relation
pg_trigger_tgrelid_tgname_index (target block 8310112): No such file or
directory

Seems like a hosed file system to me. You'll probably need to go to
backups and should do some hardware tests.

Which file system is this running on. There seem to be a large number of
people on IRC will similar problems when running on ReiserFS.

It's running on slackware linux, ext3-fs, 2.4.18 kernel, gcc 2.95.3. We
run the db with fsync=on. The was some type of system crash yesterday
so filesystem corruption is a possibility. We have all the other 7.x
series of databases running on the server and none had any troubles.

from the command line i was able to do bin/vacumdb -p5473 template1 and
I can now get in ok. Is there any way to determine if there are other
possible issues? I'm thinking of reindexing pg_trigger, should I do
more? dump/initdb/reload seems like overkill

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

On Thu, 10 Jul 2003, Christopher Kings-Lynne wrote:

Just saw this on our demo server:

root@phppgadmin:~/htdocs/webdb/conf# /usr/local/pgsql-7.3.3/bin/psql -p5473
phppgadmin
psql: FATAL: cannot open segment 1 of relation
pg_trigger_tgrelid_tgname_index (target block 8310112): No such file or
directory

There is clearly something wrong here. The block number is way too large
for a system relation.

A backtrace from the elog() would be helpful.

Thanks,

Gavin