| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | PFC <lists(at)peufeu(dot)com> |
| Cc: | "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Javier Somoza" <jsomoza(at)pandasoftware(dot)es>, "Evgeny Gridasov" <eugrid(at)fpm(dot)kubsu(dot)ru>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: wal sync method |
| Date: | 2006-02-28 23:45:06 |
| Message-ID: | 3867.1141170306@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-performance |
PFC <lists(at)peufeu(dot)com> writes:
> Just a stupid question about the various fsync settings.
> There is fsync=off, but is there fsync=fflush ?
> fflush would mean only an OS crash could cause data loss,
> I think.it could be useful for some applications where you need a speed
> boost (like testing database import scripts...) without being as scary as
> fsync=off...
I think you misunderstand. There aren't any scenarios where a PG crash
(without hardware/OS crash) risks data, because we always at least
write() data before commit. The only issue is how hard do we try to get
the OS+hardware to push that data down to disk.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2006-03-01 00:23:03 | Re: [HACKERS] pg_service.conf |
| Previous Message | PFC | 2006-02-28 23:31:33 | Re: wal sync method |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Glaesemann | 2006-03-01 03:44:25 | Re: nested query on last n rows of huge table |
| Previous Message | PFC | 2006-02-28 23:31:33 | Re: wal sync method |