From: | "Mattias Kregert" <mattias(at)kregert(dot)se> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "PostgreSQL List" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Datatypes and performance |
Date: | 2003-07-07 13:42:48 |
Message-ID: | 013c01c3448d$a7a51fc0$09000a0a@kregert.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Tom Lane wrote:
> "Mattias Kregert" <mattias(at)kregert(dot)se> writes:
> > [ misguided analysis ]
>
> > Journalling FS will fix the FS problems, so the files are ok.
> > PG journal will fix the PG problems so the tables will be ok.
>
> Only if the journal is all down to disk before the crash.
>
> The fundamental problem with fsync off is that it's likely to violate
> the WAL principle (write journal entry before data entry it describes).
> If you then crash, you have data entries that correspond to transactions
> that should not have been committed (because WAL replay won't guarantee
> recovering all of the transaction's effects). In other words, corrupt
> data.
>
> If we had a less costly way of guaranteeing write order than fsync, we'd
> use it, but there is no other portable method.
Uh oh... i thought the journal was always synced, and that the fsync option only affected table writes... :(
If I turn fsync on and then pull the power cord while a number of clients are doing lots of inserts/updates and stuff, will the fsync then guarantee that no data will be lost or corrupted?
/* m */
From | Date | Subject | |
---|---|---|---|
Next Message | Aaron Dummer | 2003-07-07 14:15:47 | Gborg is down |
Previous Message | Tom Lane | 2003-07-07 13:24:52 | Re: Datatypes and performance |