Re: WAL does not recover gracefully from out-of-disk-sp ace - Mailing list pgsql-hackers

From Tom Lane
Subject Re: WAL does not recover gracefully from out-of-disk-sp ace
Date
Msg-id 29708.984081862@sss.pgh.pa.us
Whole thread Raw
In response to RE: WAL does not recover gracefully from out-of-disk-sp ace  ("Mikheev, Vadim" <vmikheev@SECTORBASE.COM>)
List pgsql-hackers
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:
> 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-:(

True.  But at least the write is (hopefully) being done at a
non-performance-critical time.

> Probably, we need in separate process like LGWR (log writer) in Oracle.

I think the create-ahead feature in the checkpoint maker should be on
by default.

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

AFAIK, extant Unixes will not regard this as a hint at all; they'll
think it is a great opportunity to not store zeroes :-(.

One reason that I like logfile fill to be done separately is that it's
easier to convince ourselves that failure (due to out of disk space)
need not require elog(STOP) than if we have the same failure during
XLogWrite.  You are right that we don't have time to consider each STOP
in the WAL code, but I think we should at least look at that case...
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Mikheev, Vadim"
Date:
Subject: RE: Proposed WAL changes
Next
From: Bruce Momjian
Date:
Subject: Re: Performance monitor