Kevin Grittner wrote:
> >>> Bruce Momjian wrote:
> > Kevin Grittner wrote:
> >> Did you mean to say that journaled file systems are *not*
> necessary?
> >
> > Yes, not needed for database reliablity. The patch text was
> attached;
> > was it unclear?
>
> I think you accidentally left out the
>>> Bruce Momjian wrote:
> Kevin Grittner wrote:
>> Did you mean to say that journaled file systems are *not*
necessary?
>
> Yes, not needed for database reliablity. The patch text was
attached;
> was it unclear?
I think you accidentally left out the word "not".
-Kevin
--
Sent via pgsql-h
Kevin Grittner wrote:
> >>> Bruce Momjian wrote:
> > Tatsuo Ishii wrote:
> >> In your document change which one can be placed on non-journalling
> >> file system? data? wal? or both?
> >
> > Both. I have updated the docs to mention this, patch attached.
>
> Did you mean to say that journaled f
>>> Bruce Momjian wrote:
> Tatsuo Ishii wrote:
>> In your document change which one can be placed on non-journalling
>> file system? data? wal? or both?
>
> Both. I have updated the docs to mention this, patch attached.
Did you mean to say that journaled file systems are *not* necessary?
-Ke
Tatsuo Ishii wrote:
> Bruce,
>
> In your document change which one can be placed on non-journalling
> file system? data? wal? or both?
Both. I have updated the docs to mention this, patch attached.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://e
Bruce,
In your document change which one can be placed on non-journalling
file system? data? wal? or both?
For me it seems it's not clear.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> Josh Berkus wrote:
> >
> > >> First, none of the general purpose filesystems I've seen so far do data
> > >> journalli
Josh Berkus wrote:
>
> >> First, none of the general purpose filesystems I've seen so far do data
> >> journalling per default, since it's a huge performance penalty, even for
> >> non-RDBMS workloads. The feature you talk about is ext3 specific (and
> >> should be pointed out as such) and only di
First, none of the general purpose filesystems I've seen so far do data
journalling per default, since it's a huge performance penalty, even for
non-RDBMS workloads. The feature you talk about is ext3 specific (and
should be pointed out as such) and only disables write ordering, meaning
that met
Michael Renner wrote:
> Hi,
>
> the comment WRT WAL recovery and FS journals [1] is a bit misleading in
> it's current form.
>
> First, none of the general purpose filesystems I've seen so far do data
> journalling per default, since it's a huge performance penalty, even for
> non-RDBMS workloads
Hi,
the comment WRT WAL recovery and FS journals [1] is a bit misleading in
it's current form.
First, none of the general purpose filesystems I've seen so far do data
journalling per default, since it's a huge performance penalty, even for
non-RDBMS workloads. The feature you talk about is ext3 s
> Using pg_control to get checkpoint position speed up things but
> to handle possible pg_control corruption we obviously should
> implement reading existent log segments (from the last one -
> newest - to oldest) to get last checkpoint.
I think this would be *very* important :-)
Andreas
Oliver Elphick writes:
> Here's a patch to the wal.sgml text to take acocunt of Vadim's
> explanations.
I checked in your documentation plus some fixes at other places. Does
somebody care to submit some new words to describe the fsync option
(http://www.postgresql.org/devel-corner/docs/postgres
Here's a patch to the wal.sgml text to take acocunt of Vadim's
explanations.
*** wal.sgml.orig Wed Jan 24 21:55:56 2001
--- wal.sgml Wed Jan 24 22:08:44 2001
***
*** 149,154
--- 149,176
+
+ Database Recovery with WAL
+
+
+ After a checkpoint has been made and
> 1) In the 'WAL Parameters' section, paragraph 3 there is the following
> sentence: "After a checkpoint has been made, any log segments written
> before the redo record may be removed/archived..." What does the 'may'
> refer mean? Does the database administrator need to go into the
> directory
> The WAL logs auto-delete I think.
At checkpoint time.
Vadim
The WAL logs auto-delete I think.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Barry Lind
> Sent: Wednesday, January 24, 2001 12:32 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: [HACKERS] WAL documentation
>
>
> Not knowing much about WAL,
Not knowing much about WAL, but understanding a good deal about Oracle's
logs, I read the WAL documentation below. While it is good, after
reading it I am still left with a couple of questions and therefore
believe the doc could be improved a bit.
The two questions I am left with after reading t
Here is documentation for WAL, as text for immediate review and as SGML
source, generated from Vadim's original text with my editing.
Please review for correctness.
=== WAL chapter ==
Write-Ahead Logging (WAL) in Postgres
Author: Written by V
19 matches
Mail list logo
