Skip site navigation (1) Skip section navigation (2)

Re: Postgresql Performance on an HP DL385 and

From: mark(at)mark(dot)mielke(dot)cc
To: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Postgresql Performance on an HP DL385 and
Date: 2006-08-15 18:33:27
Message-ID: 20060815183327.GC12834@mark.mielke.cc (view raw or flat)
Thread:
Lists: pgsql-performance
On Tue, Aug 15, 2006 at 01:26:46PM -0400, Michael Stone wrote:
> On Tue, Aug 15, 2006 at 11:29:26AM -0500, Jim C. Nasby wrote:
> >Are 'we' sure that such a setup can't lose any data?
> Yes. If you check the archives, you can even find the last time this was 
> discussed...

I looked last night (coincidence actually) and didn't find proof that
you cannot lose data.

How do you deal with the file system structure being updated before the
data blocks are (re-)written?

I don't think you can.

> The bottom line is that the only reason you need a metadata journalling 
> filesystem is to save the fsck time when you come up. On a little 
> partition like xlog, that's not an issue.

fsck isn't only about time to fix. fsck is needed, because the file system
is broken. If the file system is broken, how can you guarantee data has
not been corrupted?

Cheers,
mark

-- 
mark(at)mielke(dot)cc / markm(at)ncf(dot)ca / markm(at)nortel(dot)com     __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/


In response to

Responses

pgsql-performance by date

Next:From: Carl YoungbloodDate: 2006-08-15 18:47:54
Subject: Re: Beginner optimization questions, esp. regarding Tsearch2
Previous:From: markDate: 2006-08-15 18:31:48
Subject: Re: Postgresql Performance on an HP DL385 and

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group