Re: Recovery of PGSQL after system crash failing!!!

From: "Vadim Mikheev" <vmikheev(at)sectorbase(dot)com>
To: "Zeugswetter Andreas SB" <ZeugswetterA(at)wien(dot)spardat(dot)at>, <thomas(at)pgsql(dot)com>, "Ryan Kirkpatrick" <pgsql(at)rkirkpat(dot)net>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Recovery of PGSQL after system crash failing!!!
Date: 2001-02-14 09:40:52
Message-ID: 002d01c0966a$39639060$4879583f@sectorbase.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > It removes the need to disable fsync to get best performance!
>
> -F performance is still better, only the difference is not so big as before.

Well, when "checkpoint seek in logs" will be implemented difference
will be the same - lost consistency.

> > Since there is a fundamental recovery problem if the WAL file
> > disappears, then perhaps we should have a workaround which can ignore
> > the requirement for that file on startup? Or maybe we do already?
> > Vadim??
>
> This was discussed, but iirc not yet implemented.

Yes & yes.

> > Also, could the "-F" option be disabled now that WAL is enabled? Or is
> > there still some reason to encourage/allow folks to use it?

I've used it when testing btree runtime recovery to increase concurrence.

> I use it, since I restore after a system crash (which never happens).
> I think all that is probably missing in -F mode is probably 2-3 fsyncs
> during checkpoint. One for the xlog, and one for pg_control (maybe also pg_log).
> All other fsyncs are only to not buffer transactions.

Probably we could just force fsync during checkpoint, for the moment.

Thanks to all for help!

Vadim

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2001-02-14 09:52:16 Re: locale support
Previous Message Zeugswetter Andreas SB 2001-02-14 08:47:22 AW: Recovery of PGSQL after system crash failing!!!