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

> Ok, I've made changes in xlog.c and run tests: 50 clients inserted
> (int4, text[1-256]) into 50 tables,
> -B 16384, -wal_buffers 256, -wal_files 0.
>
> FSYNC: 257tps
> O_DSYNC: 333tps
>
> Just(?) 30% faster, -:(

First of all, if you ask me, that is one hell of an improvement :-)
It shows, that WAL write was actually the bottleneck in this particular case.
The bottleneck may now have shifted to some other resource.

It would probably also be good, to actually write more than one
page with one call instead of the current "for (;XLByteLT...)" loop
in XLogWrite. The reasoning is, 1. that for each call to write, the OS
takes your timeslice away, allowing other backends to work,
and thus reposition the disk head (for selects).
and second measurements with tfsync.c:

zeu(at)a82101002:~> xlc -O2 tfsync.c -DINIT_WRITE -DUSE_ODSYNC -DBUFFERS=1 -o tfsync
zeu(at)a82101002:~> time tfsync
real 0m26.174s
user 0m0.040s
sys 0m2.920s
zeu(at)a82101002:~> xlc -O2 tfsync.c -DINIT_WRITE -DUSE_ODSYNC -DBUFFERS=8 -o tfsync
zeu(at)a82101002:~> time tfsync
real 0m8.950s
user 0m0.010s
sys 0m2.020s

Andreas

PS: to Tom, on AIX O_SYNC and O_DSYNC does not make a difference with tfsync.c,
both are comparable to your O_DSYNC measurements, maybe this is because of the
jfs journal, where only one write to journal is necessary for all fs work (inode...).