Thread

  1. RE: Recovery of PGSQL after system crash failing!!!

    Vadim Mikheev <vmikheev@sectorbase.com> — 2001-02-13T18:11:31Z

    > Might it be, that pg_control is older than it should be ?
    > I mean, that the write to pg_control did not make it to disk,
    > but the checkpoint already completed (removed the logs) ?
    
    Well, WAL does *pg_fsync()* of pg_control before removing old
    logs, so it's only possible if Ryan run PG with -F (fsync = off).
    Ryan?
    
    Vadim
    
    
  2. Re: Recovery of PGSQL after system crash failing!!!

    Thomas Lockhart <lockhart@alumni.caltech.edu> — 2001-02-14T01:09:15Z

    >         Guilty as charged I am afraind... :( Here, I though with WAL and
    > all (bad pun :), I would not need fsync anymore and decided to be
    > reckless. Guess I ought to reconsider that decision.... Though wasn't WAL
    > supposed to remove the need for fsync, or was it just to improve recovery
    > ablity?
    
    It removes the need to disable fsync to get best performance! The
    converse is not true; it does not eliminate the need to fsync to help
    guard data integrity, and the WAL file management may be a bit less
    robust than that for other tables. I can see how this might have been
    omitted from much of the discussion, so it is important that we remind
    ourselves about this. Thanks for the reminder :/
    
    Since there is a fundamental recovery problem if the WAL file
    disappears, then perhaps we should have a workaround which can ignore
    the requirement for that file on startup? Or maybe we do already?
    Vadim??
    
    Also, could the "-F" option be disabled now that WAL is enabled? Or is
    there still some reason to encourage/allow folks to use it?
    
                            - Thomas
    
    
  3. RE: Recovery of PGSQL after system crash failing!!!

    Ryan Kirkpatrick <pgsql@rkirkpat.net> — 2001-02-14T01:31:04Z

    On Tue, 13 Feb 2001, Mikheev, Vadim wrote:
    
    > > Might it be, that pg_control is older than it should be ?
    > > I mean, that the write to pg_control did not make it to disk,
    > > but the checkpoint already completed (removed the logs) ?
    > 
    > Well, WAL does *pg_fsync()* of pg_control before removing old
    > logs, so it's only possible if Ryan run PG with -F (fsync = off).
    > Ryan?
    
    	Guilty as charged I am afraind... :( Here, I though with WAL and
    all (bad pun :), I would not need fsync anymore and decided to be
    reckless. Guess I ought to reconsider that decision.... Though wasn't WAL
    supposed to remove the need for fsync, or was it just to improve recovery
    ablity? 
    	Anyway, if that is root of the problem, very bad timing on a
    system crash, then I will consider this problem solved. Thanks for
    everyone's help.
    
    ---------------------------------------------------------------------------
    |   "For to me to live is Christ, and to die is gain."                    |
    |                                            --- Philippians 1:21 (KJV)   |
    ---------------------------------------------------------------------------
    |   Ryan Kirkpatrick  |  Boulder, Colorado  |  http://www.rkirkpat.net/   |
    ---------------------------------------------------------------------------
    
    
    
  4. Re: Re: Recovery of PGSQL after system crash failing!!!

    Bruce Momjian <pgman@candle.pha.pa.us> — 2001-02-14T02:40:07Z

    > Since there is a fundamental recovery problem if the WAL file
    > disappears, then perhaps we should have a workaround which can ignore
    > the requirement for that file on startup? Or maybe we do already?
    > Vadim??
    > 
    > Also, could the "-F" option be disabled now that WAL is enabled? Or is
    > there still some reason to encourage/allow folks to use it?
    
    The system still fsyncs, so -F is still useful, I think.
    
    -- 
      Bruce Momjian                        |  http://candle.pha.pa.us
      pgman@candle.pha.pa.us               |  (610) 853-3000
      +  If your life is a hard drive,     |  830 Blythe Avenue
      +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
    
    
  5. Re: Re: Recovery of PGSQL after system crash failing!!!

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-02-14T04:47:15Z

    Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
    > Also, could the "-F" option be disabled now that WAL is enabled? Or is
    > there still some reason to encourage/allow folks to use it?
    
    I was the one who put it back in after Vadim turned it off ;-) ... and
    I'll object to any attempt to remove the option.
    
    I think that there's no longer any good reason for people to consider -F
    in production use.  On the other hand, for development or debugging work
    where you don't really *care* about powerfail survivability, I see no
    reason to incur extra wear on your disk drives by forcing fsyncs.  My
    drives only have so many seeks left in 'em, and I'd rather see those
    seeks expended on writing source-code files than on fsyncs of test
    databases.
    
    			regards, tom lane
    
    
  6. Re: Re: Recovery of PGSQL after system crash failing!!!

    Peter Eisentraut <peter_e@gmx.net> — 2001-02-14T17:37:57Z

    Tom Lane writes:
    
    > Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
    > > Also, could the "-F" option be disabled now that WAL is enabled? Or is
    > > there still some reason to encourage/allow folks to use it?
    >
    > I was the one who put it back in after Vadim turned it off ;-) ... and
    > I'll object to any attempt to remove the option.
    
    The description should be updated though:
    http://www.postgresql.org/devel-corner/docs/postgres/runtime-config.htm#RUNTIME-CONFIG-GENERAL
    
    I guess a lot of people have heard the rumour "PG 7.1 offers no-fsync
    performance with fsync turned on" and extrapolated "Imagine what it can do
    if I turn off fsync anyway."
    
    -- 
    Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/
    
    
    
  7. Re: Re: Recovery of PGSQL after system crash failing!!!

    Bruce Momjian <pgman@candle.pha.pa.us> — 2001-02-14T17:47:46Z

    > Tom Lane writes:
    > 
    > > Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
    > > > Also, could the "-F" option be disabled now that WAL is enabled? Or is
    > > > there still some reason to encourage/allow folks to use it?
    > >
    > > I was the one who put it back in after Vadim turned it off ;-) ... and
    > > I'll object to any attempt to remove the option.
    > 
    > The description should be updated though:
    > http://www.postgresql.org/devel-corner/docs/postgres/runtime-config.htm#RUNTIME-CONFIG-GENERAL
    > 
    > I guess a lot of people have heard the rumour "PG 7.1 offers no-fsync
    > performance with fsync turned on" and extrapolated "Imagine what it can do
    > if I turn off fsync anyway."
    
    That is a very subtle point, and one I can imagine many people
    incorrectly assuming.
    
    -- 
      Bruce Momjian                        |  http://candle.pha.pa.us
      pgman@candle.pha.pa.us               |  (610) 853-3000
      +  If your life is a hard drive,     |  830 Blythe Avenue
      +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
    
    
  8. Re: Re: Recovery of PGSQL after system crash failing!!!

    Ryan Kirkpatrick <pgsql@rkirkpat.net> — 2001-02-16T04:53:52Z

    On Wed, 14 Feb 2001, Peter Eisentraut wrote:
    
    > Tom Lane writes:
    > 
    > > Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
    > > > Also, could the "-F" option be disabled now that WAL is enabled? Or is
    > > > there still some reason to encourage/allow folks to use it?
    > >
    > > I was the one who put it back in after Vadim turned it off ;-) ... and
    > > I'll object to any attempt to remove the option.
    > 
    > The description should be updated though:
    > http://www.postgresql.org/devel-corner/docs/postgres/runtime-config.htm#RUNTIME-CONFIG-GENERAL
    > 
    > I guess a lot of people have heard the rumour "PG 7.1 offers no-fsync
    > performance with fsync turned on" and extrapolated "Imagine what it can do
    > if I turn off fsync anyway."
    
    	That is exactly what I did... Figured that will WAL removing the
    need for fsync, it wasn't needed and could be disabled for a nice
    perfomance increase. Now I am quite a bit wiser, and will be leaving
    fsyncing enabled on all 7.1 production servers. :) 
    	Thank you for bring that subtle point out and yes, the documention
    could do with a bit of help on this point. TTYL.
    
    ---------------------------------------------------------------------------
    |   "For to me to live is Christ, and to die is gain."                    |
    |                                            --- Philippians 1:21 (KJV)   |
    ---------------------------------------------------------------------------
    |   Ryan Kirkpatrick  |  Boulder, Colorado  |  http://www.rkirkpat.net/   |
    ---------------------------------------------------------------------------