Thread
-
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
-
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 -
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/ | ---------------------------------------------------------------------------
-
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
-
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
-
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/
-
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
-
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/ | ---------------------------------------------------------------------------