Re: [HACKERS] 9.6 and fsync=off

On Mon, May 2, 2016 at 12:04 PM, Tom Lane wrote: > Andres Freund writes: >> On 2016-05-02 10:07:50 -0400, Robert Haas wrote: >>> - If that flag is set on a subsequent startup, say: >>> WARNING: Recovery was previously performed with fsync=off; this >>> cluster may be irretrievably corrupted. > >>

Re: [HACKERS] 9.6 and fsync=off

Andres Freund writes: > On 2016-05-02 10:07:50 -0400, Robert Haas wrote: >> - If that flag is set on a subsequent startup, say: >> WARNING: Recovery was previously performed with fsync=off; this >> cluster may be irretrievably corrupted. > Well, the problem with that is that postgres crashes are

Re: [HACKERS] 9.6 and fsync=off

Hi, On 2016-05-02 10:07:50 -0400, Robert Haas wrote: > I also think that it would be a swell idea to detect whether a system > has ever crashed with fsync=off, and do something about that, like > maybe bleat on every subsequent startup for the lifetime of the > cluster. I think Andres may have ev

Re: [HACKERS] 9.6 and fsync=off

Craig Ringer writes: > On 2 May 2016 at 22:07, Robert Haas wrote: >> I also think that it would be a swell idea to detect whether a system >> has ever crashed with fsync=off, and do something about that, like >> maybe bleat on every subsequent startup for the lifetime of the >> cluster. > Yes. V

Re: [HACKERS] 9.6 and fsync=off

On 2 May 2016 at 22:07, Robert Haas wrote: > > I also think that it would be a swell idea to detect whether a system > has ever crashed with fsync=off, and do something about that, like > maybe bleat on every subsequent startup for the lifetime of the > cluster. Yes. Very, very yes. That woul

Re: [HACKERS] 9.6 and fsync=off

On Fri, Apr 29, 2016 at 9:49 AM, Tom Lane wrote: > Abhijit Menon-Sen writes: >> Do you want a patch along those lines now, or is it too late? > > We're certainly not going to consider fooling with this in 9.6. > The situation for manual fsync-twiddling is no worse than it was in > any prior relea

Re: [HACKERS] 9.6 and fsync=off

Abhijit Menon-Sen writes: > Do you want a patch along those lines now, or is it too late? We're certainly not going to consider fooling with this in 9.6. The situation for manual fsync-twiddling is no worse than it was in any prior release, and we are long past feature freeze. If you want to put

Re: [HACKERS] 9.6 and fsync=off

At 2016-04-28 13:44:23 -0700, and...@anarazel.de wrote: > > Abhijit had a patch implementing automatically running fsync whenever > reenabled IIRC. Abhijit? The patch I had written is attached, and it's not quite the same thing. Here's how I originally described it in response to a question from R

Re: [HACKERS] 9.6 and fsync=off

On 2016-04-28 21:32:37 +0200, Simon Riggs wrote: > On 27 April 2016 at 17:04, Craig Ringer wrote: > > > On 27 April 2016 at 21:44, Tom Lane wrote: > > > >> Petr Jelinek writes: > >> > +1 (Abhijit's wording with data loss changed to data corruption) > >> > >> I'd suggest something like > >> > >>

Re: [HACKERS] 9.6 and fsync=off

On 28 April 2016 at 22:30, David G. Johnston wrote: > On Thursday, April 28, 2016, Simon Riggs wrote: > >> On 27 April 2016 at 17:04, Craig Ringer wrote: >> >>> On 27 April 2016 at 21:44, Tom Lane wrote: >>> Petr Jelinek writes: > +1 (Abhijit's wording with data loss changed to data

Re: [HACKERS] 9.6 and fsync=off

On Thursday, April 28, 2016, Simon Riggs wrote: > On 27 April 2016 at 17:04, Craig Ringer > wrote: > >> On 27 April 2016 at 21:44, Tom Lane > > wrote: >> >>> Petr Jelinek >> > writes: >>> > +1 (Abhijit's wording with data loss changed to data corruption) >>> >>> I'd suggest something like >>> >>

Re: [HACKERS] 9.6 and fsync=off

On 27 April 2016 at 17:04, Craig Ringer wrote: > On 27 April 2016 at 21:44, Tom Lane wrote: > >> Petr Jelinek writes: >> > +1 (Abhijit's wording with data loss changed to data corruption) >> >> I'd suggest something like >> >> #fsync = on # flush data to disk for cra

Re: [HACKERS] 9.6 and fsync=off

On Wed, Apr 27, 2016 at 10:58 AM, Craig Ringer wrote: > Now, we can't rename fsync to disable_crash_safety=on or > corrupt_my_database=on. But the comment needs changing. Fwiw we've done similar things in the past. We can provide backwards-compatibility support for "fsync" but make the setting a

Re: [HACKERS] 9.6 and fsync=off

On Wed, Apr 27, 2016 at 11:04 AM, Craig Ringer wrote:>> I'd suggest something like >> >> #fsync = on # flush data to disk for crash >> safety >> # (turning this off can cause >> # unrecovera

Re: [HACKERS] 9.6 and fsync=off

On 27 April 2016 at 21:44, Tom Lane wrote: > Petr Jelinek writes: > > +1 (Abhijit's wording with data loss changed to data corruption) > > I'd suggest something like > > #fsync = on # flush data to disk for crash > safety > # (t

Re: [HACKERS] 9.6 and fsync=off

Petr Jelinek writes: > +1 (Abhijit's wording with data loss changed to data corruption) I'd suggest something like #fsync = on # flush data to disk for crash safety # (turning this off can cause

Re: [HACKERS] 9.6 and fsync=off

Here's a patch just to help things along. -- Abhijit diff --git a/src/backend/utils/misc/postgresql.conf.sample b/src/backend/utils/misc/postgresql.conf.sample index f3e3de0..353de2e 100644 --- a/src/backend/utils/misc/postgresql.conf.sample +++ b/src/backend/utils/misc/postgresql.conf.sample @@ -

Re: [HACKERS] 9.6 and fsync=off

On 27/04/16 12:53, Magnus Hagander wrote: On Wed, Apr 27, 2016 at 12:43 PM, Abhijit Menon-Sen mailto:a...@2ndquadrant.com>> wrote: At 2016-04-27 17:58:08 +0800, cr...@2ndquadrant.com wrote: > > #fsync = on # turns force

Re: [HACKERS] 9.6 and fsync=off

On Wed, Apr 27, 2016 at 12:43 PM, Abhijit Menon-Sen wrote: > At 2016-04-27 17:58:08 +0800, cr...@2ndquadrant.com wrote: > > > > #fsync = on # turns forced synchronization > on or off > > I suggest:# provide crash safety by > flushing dis

Re: [HACKERS] 9.6 and fsync=off

At 2016-04-27 17:58:08 +0800, cr...@2ndquadrant.com wrote: > > #fsync = on # turns forced synchronization on or > off I suggest:# provide crash safety by flushing disk writes # (Disabling this c