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