From: | Marko Kreen <marko(at)l-t(dot)ee> |
---|---|
To: | Magnus Hagander <mha(at)sollentuna(dot)net> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Simplifying wal_sync_method |
Date: | 2005-08-09 10:30:34 |
Message-ID: | 20050809103033.GA25492@l-t.ee |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Aug 09, 2005 at 12:14:09PM +0200, Magnus Hagander wrote:
> > > That can definitly be debated. Properly maintaned on proper
> > hardware,
> > > it's quite reliable these days.
> > > Most filesystem corruptions that happen on windows are
> > because people
> > > enable write caching on drives without battery backup. The
> > same issue
> > > we're facing here, it's *not* a problem in the fs, it's a
> > problem in
> > > the admin. Sure, there are lots of things that could be better with
> > > ntfs, but I would definitly not call it unreliable.
> >
> > People enable? Isn't it the default?
>
> I dunno about workstation OS, but on the server OSes it certainly isn't
> default.
At least on XP Pro it is default.
> > The professional probably tests it on his own desktop. I
> > don't think PostgreSQL reaches the data center before passing
> > the run on desktop.
>
> I can't speak for others, but I would always test a server product on a
> server OS on server hardware. Certainly not as beefy as eventual
> production server, but the same level. Otherwise the test is not fully
> relevant.
You are right, but it always does not happen so. Also think of
developers who run a dev-server on a desktop.
> > > > Why shouldn't we offer reliable option to win32?
> > >
> > > *we do offer a reliabel option*.
> > > Same as on POSIX, we don't enable it by default for *non-server
> > > hardware*.
> >
> > What do you mean here? AFAIK we try to be reliable on POSIX too.
>
> AFAIK fsync is slightly safer than open_sync, because it also flushes
> the metadata. We don't default to that.
At least for WAL, the metadata does not change so it should not matter.
Now thinking about it, the guy had corrupt table, not WAL log.
How is WAL->tables synched? Does the 'wal_sync_method' affect
it or not?
Ofcourse, postgres could get corrupt data from WAL and put it
into table. (AFAIK NTFS does not log data, so we are back on
wal_sync_method.)
> > > > Options:
> > > >
> > > > - Win32 guy complains that PG is bit slow.
> > > > We tell him to RTFM.
> > >
> > > What most often happens here is:
> > > Win32 guy notices PG is very slow, changes to mysql or mssql.
> >
> > But lost database is no problem?
>
> It certainly is. That's not what I'm arguing. What I'm saying is that
> you shouldn't expect server grade reliabilty on desktop hardware and
> desktop OS. Regardless of platform.
But we should expect server-grade speed? ;)
--
marko
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2005-08-09 10:58:31 | Re: Simplifying wal_sync_method |
Previous Message | Magnus Hagander | 2005-08-09 10:14:09 | Re: Simplifying wal_sync_method |