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

> I tried this on HPUX 10.20, which has not only O_SYNC but also O_DSYNC
> (defined to do the equivalent of fdatasync()), and got truly
> fascinating results. Apparently, on this platform these flags change
> the kernel's buffering behavior! Observe:

Solaris 2.6 fascinates even more!!!

> $ gcc -Wall -O -DINIT_WRITE -DUSE_ODSYNC tfsync.c
> $ time a.out
>
> real 0m21.40s
> user 0m0.02s
> sys 0m0.60s

bash-2.02# gcc -Wall -O -DINIT_WRITE -DUSE_ODSYNC tfsync.c
bash-2.02# time a.out

real 0m4.242s
user 0m0.000s
sys 0m0.450s

It's hard to believe... Writing with DSYNC takes the same time as
file initialization - ~2 sec.
Also, there is no difference if using 64k blocks.
INIT_WRITE + OSYNC gives 52 sec for 8k blocks and 5.7 sec
for 256k ones, but INIT_WRITE + DSYNC doesn't depend on block
size.
Modern IDE drive? -:))

Probably we should change code to use O_DSYNC if defined even without
changing XLogWrite to write more than 1 block at once (if requested)?

As for O_SYNC:

bash-2.02# gcc -Wall -O -DINIT_WRITE tfsync.c
bash-2.02# time a.out

real 0m54.786s
user 0m0.010s
sys 0m10.820s
bash-2.02# gcc -Wall -O -DINIT_WRITE -DUSE_OSYNC tfsync.c
bash-2.02# time a.out

real 0m52.406s
user 0m0.020s
sys 0m0.650s

Not big win. Solaris has more optimized search for dirty blocks
than Tom' HP and Andreas' platform?

Vadim