Re: AW: AW: AW: AW: WAL does not recover gracefully from ou t-of -dis k-sp ace

Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> writes:
>> I attach my modified version of Andreas' program. Note I do not
>> believe his assertion that close() implies fsync() --- on the
>> machines I've used, it demonstrably does not sync.

> Ok, I am not sure, but essentially do we need it to sync? The OS sure isn't
> supposed to notice after closing the file, that it ran out of disk space.

I believe that out-of-space would be reported during the writes, anyway,
so that's not the issue.

The point of fsync'ing after the prewrite is to ensure that the indirect
blocks are down on disk. If you trust fdatasync (or O_DSYNC) to write
indirect blocks then it's not necessary --- but I'm pretty sure I heard
somewhere that some versions of fdatasync fail to guarantee that.

In any case, the real point of the prewrite is to move work out of the
transaction commit path, and so we're better off if we can sync the
indirect blocks during prewrite.

>> I tried this on HPUX 10.20, which has not only O_SYNC but also O_DSYNC

> AIX has O_DSYNC (which is _FDATASYNC) too, but I assumed O_SYNC

Oh? What speeds do you get if you use that?

regards, tom lane