From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Remove fsync ON/OFF as a visible option? |
Date: | 2015-03-25 19:45:42 |
Message-ID: | 55131066.4020904@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 3/21/15 12:25 PM, Jeff Janes wrote:
> On Sat, Mar 21, 2015 at 8:54 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us
> <mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us>> wrote:
>
> Stephen Frost <sfrost(at)snowman(dot)net <mailto:sfrost(at)snowman(dot)net>> writes:
> > At the moment, one could look at our default postgresql.conf and the
> > "turns forced synchronization on or off" and think it's something akin
> > or somehow related to synchronous_commit (which is completely different,
> > but the options are right next to each other..).
>
> > How about a big warning around fsync and make it more indepenent from
> > the options around it?
>
> Yeah, the main SGML docs are reasonably clear about the risks of fsync,
> but postgresql.conf doesn't give you any hint that it's dangerous. Now
> I'm not entirely sure that people who frob postgresql.conf without
> having
> read the docs can be saved from themselves, but we could do something
> like this:
>
> # - Settings -
>
> #wal_level = minimal # minimal, archive,
> hot_standby, or logical
> # (change requires restart)
> #fsync = on # turns forced
> synchronization on or off
> + # (fsync=off is dangerous,
> read the
> + # (manual before using it)
> #synchronous_commit = on # synchronization level;
> # off, local, remote_write,
> or on
> #wal_sync_method = fsync # the default is the first
> option
> # supported by the
> operating system:
>
> Also, I think the short description "turns forced synchronization on or
> off" could stand improvement; it really conveys zero information. Maybe
> something like "force data to disk when committing"?
>
>
> I agree the current description is lacking, but that proposed wording
> would be a better description of synchronous_commit. It is
> checkpointing and flush-WAL-before-data where fsync=off does its damage.
> "Force data to disk when needed for integrity"?
>
> Or just don't describe what it is at all, and refer to the documentation
> only.
I see 3 settings that allow people to accidentally shoot themselves in
the foot; fsync, wal_sync_method and full_page_writes.
How about just grouping those 3 together with a bulk disclaimer along
the lines of "The following 3 settings are dangerous. Use at your own
risk, and read the docs first."? That would also allow us to just remove
the comments about what the settings do; if you don't already know you
certainly shouldn't be touching them! :)
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2015-03-25 20:02:46 | Re: Reduce pinning in btree indexes |
Previous Message | Anastasia Lubennikova | 2015-03-25 19:30:12 | Re: GSoC 2015 proposal. Bitmap Index-only Count |