| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| To: | Magnus Hagander <mha(at)sollentuna(dot)net> |
| Cc: | Marko Kreen <marko(at)l-t(dot)ee>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Simplifying wal_sync_method |
| Date: | 2005-08-09 14:18:52 |
| Message-ID: | 20050809141852.GC19070@alvh.no-ip.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Aug 09, 2005 at 04:05:28PM +0200, Magnus Hagander wrote:
> > > > 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.
> >
> > No. If fsync is off, then no fsync is done to the data files
> > on checkpoint either. (See mdsync() on src/backend/storage/smgr/md.c)
>
> Right, but we're not talking fsync=off, we're talking when you are using
> fdatasync, O_SYNC etc.
Oh, sorry :-) At that point, pg_fsync is called, which can invoke
commit() or fsync() depending on whether you have writethrough enabled.
pg_fsync() on storage/file/fd.c
--
Alvaro Herrera (<alvherre[a]alvh.no-ip.org>)
FOO MANE PADME HUM
| From | Date | Subject | |
|---|---|---|---|
| Next Message | mark | 2005-08-09 14:22:31 | Re: Simplifying wal_sync_method |
| Previous Message | Magnus Hagander | 2005-08-09 14:05:28 | Re: Simplifying wal_sync_method |