| From: | "Magnus Hagander" <mha(at)sollentuna(dot)net> |
|---|---|
| To: | "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us> |
| Cc: | "Marko Kreen" <marko(at)l-t(dot)ee>, "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 14:56:32 |
| Message-ID: | 6BCB9D8A16AC4241919521715F4D8BCE6C7860@algol.sollentuna.se |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > > 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.
>
> wal_sync_method is also used to flush pages during a
> checkpoint, so it could lead to table corruption too, not
> just WAL corruption.
>
> However, on Unix, 99% of corruption is caused by bad disk or RAM.
... or iDE disks with write cache enabled. I've certainly seen more than
what I'd call 1% (though I haven't studied it to be sure) that's because
of write-cached disks...
//Magnus
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2005-08-09 14:58:13 | Re: Simplifying wal_sync_method |
| Previous Message | Bruce Momjian | 2005-08-09 14:53:39 | Re: Simplifying wal_sync_method |