Re: How to reset WAL enveironment - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject Re: How to reset WAL enveironment
Date
Msg-id 3A2E0B31.4758C539@tpf.co.jp
Whole thread Raw
In response to RE: How to reset WAL enveironment  ("Mikheev, Vadim" <vmikheev@SECTORBASE.COM>)
List pgsql-hackers
Mikheev, Vadim wrote:
>
> > > > FATAL 2:  btree_insert_redo: uninitialized page
> > > >
> > > > Is it a bug ?
> > >
> > > Seems so. btree_insert_redo shouldn't see uninitialized pages
> > > (only newroot and split ops add pages to index and they should
> > > be redone before insert op).
> > > Can you post/ftp me tgz of data dir?
> > > Or start up postmaster with --wal_debug=1 and send me
> > > output.
> > >
> >
> > Probably this is caused by my trial (local) change
> > and generated an illegal log output.
> > However it seems to mean that WAL isn't always
> > redo-able.
>
> Illegal log output is like disk crash - only BAR can help.


But redo-recovery after restore would also fail.
The operation which corresponds to the illegal
log output aborted at the execution time and
rolling back by redo also failed. It seems
preferable to me that the transaction is rolled
back by undo.

> I agree that elog(STOP) caused by problems with single
> data file is quite annoying, it would be great if we could
> mark table/index as corrupted after recovery, but there are
> no means for this now. For the moment we can only notify
> DBA about problems with file node and ignore further
> recovery of corresponding table/index - I'll do this
> for beta2/3 if no one else.
>
> > In my case the index is probably a
> > system index unfortunately. Is there a way to
>
> Your REINDEX works very well.
>

OK,the indexes of pg_class were recovered by REINDEX.

Regards.

Hiroshi Inoue


pgsql-hackers by date:

Previous
From: Bernard Frankpitt
Date:
Subject: Re: [GENERAL] RE: Indexing for geographic objects?
Next
From: mlw
Date:
Subject: Function returning tuples.