RE: How to reset WAL enveironment

From: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>
To: "'Hiroshi Inoue'" <Inoue(at)tpf(dot)co(dot)jp>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: RE: How to reset WAL enveironment
Date: 2000-12-06 04:24:50
Message-ID: 8F4C99C66D04D4118F580090272A7A234D31D0@sectorbase1.sectorbase.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

> > > 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.
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.

> avoid invoking recovery process at startup ?

You would get totally corrupted database. Remember -
WAL avoids not only fsync() but write() too.

Vadim

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2000-12-06 04:48:37 Re: Overhead of tables.
Previous Message ashley 2000-12-06 04:16:07 Clarification

Browse pgsql-hackers by date

  From Date Subject
Next Message Denis Perchine 2000-12-06 04:51:09 Strange messages in log.
Previous Message Hiroshi Inoue 2000-12-06 02:30:22 Re: How to reset WAL enveironment