Re: Simplifying wal_sync_method

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Simplifying wal_sync_method
Date: 2005-08-09 05:08:01
Message-ID: 200508090508.j79581Y14481@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > No one is every going to do it, so we might as well make the best guess
> > we have. I think any platform where the *data* options are slower than
> > the non-*data* options is broken, and if that logic holds, we might as
> > well just use *data* by default if we can, which is my proposal.
>
> Adjusting the default settings I don't have a problem with. Removing
> options I have a problem with --- and that appeared to be what you
> were proposing.

Well, right now we support:

* open_datasync (write WAL files with open() option O_DSYNC)
* fdatasync (call fdatasync() at each commit),
* fsync (call fsync() at each commit)
* fsync_writethrough (force write-through of any disk write cache)
* open_sync (write WAL files with open() option O_SYNC)

and we pick the first supported item as the default. I have updated our
documentation to clarify this.

My proposal is to remove fdatasync and open_datasync, and have have
fsync _prefer_ fdatasync, and open_sync prefer open_datastync, but fall
back to fsync and open_sync if the *data* version are not supported.

We have flexibility by having more options, but we also have complexity
of having options that have never proven to be useful in the years we
have had them, namely using fsync if fdatasync is supported.

If we remove the *data* spellings, we can probably support both
open_sync and fsync on all platforms because the *data* varieties are
the ones that are not always supported.

One problem is that by removing the *data* versions, you would never
know if you were calling fsync or fdatasync internally.

We also need to re-test these defaults because we now have O_DIRECT and
groups writes of WAL.

If we test using the build farm, if we test two options and alternate
the tests, and one is always faster than the other, I think we can
conclude that that one is faster, even if there are other loads on the
system.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2005-08-09 05:17:11 Re: Simplifying wal_sync_method
Previous Message Jeffrey W. Baker 2005-08-09 05:03:19 Re: Simplifying wal_sync_method