Testing structure (was) Re: Allowing WAL fsync to be done via O_SYNC

Is someone able to put together a testing-type script or sequence so
people can run this on the various platforms and then report the
results?

For example, I can setup benchmarking, (or automated testing) on various
Solaris platforms to run overnight and report the results in the
morning. I suspect that quite a few people can do similar.

Would this be a good thing for someone to spend some time and effort on,
in generating testing-type scripts/structures? It might be a useful
tool to use in the future when making performance/related decisions like
this.

Regards and best wishes,

Justin Clift

Tom Lane wrote:
>
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > I later read Vadim's comment that fsync() of two blocks may be faster
> > than two O_* writes, so I am now confused about the proper solution.
> > However, I think we need to pick one and make it invisible to the user.
> > Perhaps a compiler/config.h flag for testing would be a good solution.
>
> I believe that we don't know enough yet to nail down a hard-wired
> decision. Vadim's idea of preferring O_DSYNC if it appears to be
> different from O_SYNC is a good first cut, but I think we'd better make
> it possible to override that, at least for testing purposes.
>
> So I think it should be configurable at *some* level. I don't much care
> whether it's a config.h entry or a GUC variable.
>
> But consider this: we'll be more likely to get some feedback from the
> field (allowing us to refine the policy in future releases) if it is a
> GUC variable. Not many people will build two versions of the software,
> but people might take the trouble to play with a run-time configuration
> setting.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster