RE: [BUGS] Loosing files after backend crash

From: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>
To: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: ???????????? ?????????? <ks(at)tcnet(dot)ru>, "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: [BUGS] Loosing files after backend crash
Date: 2001-04-03 23:36:48
Message-ID: 8F4C99C66D04D4118F580090272A7A234D336F@sectorbase1.sectorbase.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> >> Hmm. Maybe the WAL redo is messing things up??
>
> > It could mess up pg_class content, but it never deletes
> > files (currently).
>
> I'm not convinced that any files have really been deleted. Maybe it's
> just that the pg_class entries are wrong, or even more likely that the
> indexes on pg_class are messed up (pointing at the wrong
> pg_class rows).

1. Indices could be recreated with REINDEX or pg_class could be queried
with seq scan (something like where relname like '%seq_i___data_buffer%')...
Konstantin?

2. While trying to reproduce this case (without success yet) I've noticed
that in the event of crash just after creation sequence would miss
magic number and so nextval would abort. Fixed. Looks like not related
to reported problem, though.

3. Could you help us reproduce this bug, Konstantin?
What exactly did you do after sequence creation?
Does your function reference temp table you've mentioned?
What cause crash? Maybe crash is related somehow...
Could you try to reproduce failure with wal_debug = 1 and
post me postmaster' log?

Regards,
Vadim

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Myers 2001-04-04 00:54:05 Re: Re: Final call for platform testing
Previous Message Thomas Lockhart 2001-04-03 23:19:04 Re: Final call for platform testing