> > I dunno about workstation OS, but on the server OSes it certainly
> > isn't default.
>
> At least on XP Pro it is default.
Yuck.
> > > 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.
Well, with developers losing your data really isn't all that bad. It's a lot
easier to deal with than losing a server :-)
> > > > > 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.
In most cases, right. In some cases it does (create a new WAL log segment for
example). It's not a very common scenario, but I've seen error reports saying
that an entire WAL segment is missing which is probably from metadata not being
on disk at crash time.
(This is one thing that's "better" with the dbs that stuff evrything in a
single precreated file (for example mssql) - the only metadata in the
filesystem there is the "latest write time", which is completely irrelevant to
the data)
> 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?
I *think* it always fsyncs() there as it is now, but I'm not 100% sure.
> 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.)
Correct, and I beleive that's true for most Unix journaling fs:s as well - they
only journal metadata.
Also, once a checkpoint has occured, postgresql will discard the WAL log. If
the sync came through for the checkpoint record in the WAL file but not in the
contents of the datafile, the recovery process will think that the file is ok
even though it isn't.
> > 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? ;)
Touché :-)
//Magnus
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
