| From: | Chris Bitmead <chrisb(at)nimrod(dot)itg(dot)telstra(dot)com(dot)au> |
|---|---|
| To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
| Cc: | Alfred Perlstein <bright(at)wintelcom(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, pgsql-hackers(at)postgreSQL(dot)org |
| Subject: | Re: fsync alternatives (was: Re: [HACKERS] TODO item) |
| Date: | 2000-02-07 23:32:51 |
| Message-ID: | 389F5623.EB540669@nimrod.itg.telecom.com.au |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Bruce Momjian wrote:
>
> > > So, I think we are safe if we can either keep that file descriptor open
> > > until commit, or re-open it and fsync it on commit. That assume a
> > > re-open is hitting the same file. My opinion is that we should just
> > > fsync it on close and not worry about a reopen.
> >
> > I'm pretty sure that the standard is that a close on a file _should_
> > fsync it.
>
> This is not true. close flushes the user buffers to kernel buffers. It
> does not force to physical disk in all cases, I think.
fclose flushes user buffers to kernel buffers. close only frees the file
descriptor for re-use.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2000-02-07 23:34:59 | Re: [HACKERS] TODO item |
| Previous Message | Tom Lane | 2000-02-07 23:30:51 | Re: [HACKERS] network_ops in 7.0 and pg_dump question |