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

"Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)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