Various serverlog messages

CSN <cool_screen_name90001@yahoo.com> writes:

I was looking through my serverlog and there are a few
items I have questions about:

LOG: recycled transaction log file 00000000000000AD
LOG: recycled transaction log file 00000000000000AE
LOG: recycled transaction log file 00000000000000AF
LOG: pq_recvbuf: unexpected EOF on client connection

These are routine (that's why they're marked LOG).

ERROR: _mdfd_getrelnfd: cannot open relation
pg_toast_16384_index: No such file or directory

This is definitely not routine. Assuming you're running 7.3,
this seems to indicate that you've lost the toast index for
pg_attrdef. Which would be a bad thing, although we can hope
that maybe you didn't have any default expressions long enough
to need to be toasted.

Could we see the output of
select oid,* from pg_class where relname = 'pg_toast_16384_index';
(you should repeat this in each of your databases to make sure
they all give the same answers).

Are you able to do a pg_dump?

regards, tom lane

--- Tom Lane <tgl@sss.pgh.pa.us> wrote:

ERROR: _mdfd_getrelnfd: cannot open relation
pg_toast_16384_index: No such file or directory

This is definitely not routine. Assuming you're
running 7.3,
this seems to indicate that you've lost the toast
index for
pg_attrdef. Which would be a bad thing, although we
can hope
that maybe you didn't have any default expressions
long enough
to need to be toasted.

Could we see the output of
select oid,* from pg_class where relname =
'pg_toast_16384_index';
(you should repeat this in each of your databases to
make sure
they all give the same answers).

Are you able to do a pg_dump?

Yes, pg_dump and pg_dumpall appear to work fine. The
output for all of the dbs (except one) for the select
above is:

oid | relname | relnamespace | reltype
| relowner | relam | relfilenode | relpages |
reltuples | reltoastrelid | reltoastidxid |
relhasindex | relisshared | relkind | relnatts |
relchecks | reltriggers | relukeys | relfkeys |
relrefs | relhasoids | relhaspkey | relhasrules |
relhassubclass | relacl
-------+----------------------+--------------+---------+----------+-------+-------------+----------+-----------+---------------+---------------+-------------+-------------+---------+----------+-----------+-------------+----------+----------+---------+------------+------------+-------------+----------------+--------
16656 | pg_toast_16384_index | 99 | 0
| 1 | 403 | 16656 | 1 |
0 | 0 | 0 | f | f
| i | 2 | 0 | 0
| 0 | 0 | 0 | f | f
| f | f |
(1 row)

Here's the exception:

oid | relname | relnamespace | reltype
| relowner | relam | relfilenode | relpages |
reltuples | reltoastrelid | reltoastidxid |
relhasindex | relisshared | relkind | relnatts |
relchecks | reltriggers | relukeys | relfkeys |
relrefs | relhasoids | relhaspkey | relhasrules |
relhassubclass | relacl
-------+----------------------+--------------+---------+----------+-------+-------------+----------+-----------+---------------+---------------+-------------+-------------+---------+----------+-----------+-------------+----------+----------+---------+------------+------------+-------------+----------------+--------
16656 | pg_toast_16384_index | 99 | 0
| 1 | 403 | 3682590432 | 1 |
0 | 0 | 0 | f | f
| i | 2 | 0 | 0
| 0 | 0 | 0 | f | f
| f | f |
(1 row)

The 3682590432 value.

BTW, what is toast (for big fields?) and (toasted)
default expressions?

TIA,
CSN

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

CSN <cool_screen_name90001@yahoo.com> writes:

Yes, pg_dump and pg_dumpall appear to work fine. The
output for all of the dbs (except one) for the select
above is:
[ normal looking ]
Here's the exception:

16656 | pg_toast_16384_index | 99 | 0
| 1 | 403 | 3682590432 | 1 |
0 | 0 | 0 | f | f
| i | 2 | 0 | 0
| 0 | 0 | 0 | f | f
| f | f |
(1 row)

Sure enough, the relfilenode column (which determines the actual on-disk
filename) is clobbered.  Weird as can be ... could you have suffered a
hardware glitch affecting just that one word?  Doesn't seem real likely
--- the glitches I've seen in the past tend to take out more than a word
at a time.  But it's not easy to credit as a software error either.

You could fix this database with a quick UPDATE command to set
relfilenode back to what it should be in this pg_class row. However,
it'd be wise to wonder what other issues might be lurking. If I were
you I'd do a pg_dumpall/initdb/reload cycle, and also spend some time on
hardware testing (if you're on Intel hardware, memtest86 has a good
reputation for finding RAM problems, and people have successfully found
disk problems with badblocks).

regards, tom lane

If an IDE drive has a bad block, doesn't it just mark the block as bad
and map in a new one, perhaps taking as much of the old block as it can?
Maybe that is the cause.

From my experience, SCSI reports a block error and will not read it.

---------------------------------------------------------------------------

Tom Lane wrote:

CSN <cool_screen_name90001@yahoo.com> writes:

Yes, pg_dump and pg_dumpall appear to work fine. The
output for all of the dbs (except one) for the select
above is:
[ normal looking ]
Here's the exception:

16656 | pg_toast_16384_index | 99 | 0
| 1 | 403 | 3682590432 | 1 |
0 | 0 | 0 | f | f
| i | 2 | 0 | 0
| 0 | 0 | 0 | f | f
| f | f |
(1 row)

Sure enough, the relfilenode column (which determines the actual on-disk
filename) is clobbered.  Weird as can be ... could you have suffered a
hardware glitch affecting just that one word?  Doesn't seem real likely
--- the glitches I've seen in the past tend to take out more than a word
at a time.  But it's not easy to credit as a software error either.

You could fix this database with a quick UPDATE command to set
relfilenode back to what it should be in this pg_class row. However,
it'd be wise to wonder what other issues might be lurking. If I were
you I'd do a pg_dumpall/initdb/reload cycle, and also spend some time on
hardware testing (if you're on Intel hardware, memtest86 has a good
reputation for finding RAM problems, and people have successfully found
disk problems with badblocks).

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073