Обсуждение: Various serverlog messages
I was looking through my serverlog and there are a few items I have questions about: ERROR: _mdfd_getrelnfd: cannot open relation pg_toast_16384_index: No such file or directory LOG: recycled transaction log file 00000000000000AB LOG: recycled transaction log file 00000000000000AC 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 ERROR: _mdfd_getrelnfd: cannot open relation pg_toast_16384_index: No such file or directory LOG: recycled transaction log file 00000000000000B0 Anything to worry about? What's the message about the toast index mean - db corruption? What are the recycled transaction log messages about? Do I need to worry about ID's wrapping? CSN __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
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