RE: WAL does not recover gracefully from out-of-disk-sp ace

From: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>
To: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: RE: WAL does not recover gracefully from out-of-disk-sp ace
Date: 2001-03-08 17:56:24
Message-ID: 8F4C99C66D04D4118F580090272A7A234D3300@sectorbase1.sectorbase.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > I see that seek+write was changed to write-s in XLogFileInit
> > (that was induced by subj, right?), but what about problem
> > itself?
>
> > BTW, were performance tests run after seek+write --> write-s
> > change?
>
> That change was for safety, not for performance. It might be a
> performance win on systems that support fdatasync properly (because it
> lets us use fdatasync), otherwise it's probably not a performance win.

Even with true fdatasync it's not obviously good for performance - it takes
too long time to write 16Mb files and fills OS buffer cache with trash-:(
Probably, we need in separate process like LGWR (log writer) in Oracle.
I also like the Andreas idea about re-using log files.

> But we need it regardless --- if you didn't want a fully-allocated WAL
> file, why'd you bother with the original seek-and-write-1-byte code?

I considered this mostly as hint for OS about how log file should be
allocated (to decrease fragmentation). Not sure how OSes use such hints
but seek+write costs nothing.

Vadim

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2001-03-08 18:34:38 Checkpoint process signal handling seems wrong
Previous Message Bruce Momjian 2001-03-08 17:35:54 Re: Performance monitor