From: | Vadim Mikheev <vadim(at)krs(dot)ru> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Postgres Speed or lack thereof |
Date: | 1999-01-19 05:37:19 |
Message-ID: | 36A41A0F.8E24F3F2@krs.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
>
> Vadim Mikheev <vadim(at)krs(dot)ru> writes:
> > Tom Lane wrote:
> >> However, with a UPS and an OS that only crashes about once every
> >> other year, I feel pretty secure using -F ...
>
> > However, it's easy to crash Postgres itself and lose
> > committed transactions -:(
>
> Surely not? The docs say (and a quick look at the code confirms)
> that -F suppresses calls to fsync(2). It does not suppress writes.
> Thus, a commit will still write the data out to kernel disk buffers.
> All that fsync does is force the kernel to execute immediate disk
> writes for those buffers. If I don't fsync, and the backend crashes,
> the modified file data is still in kernel disk buffers and the kernel
> is still responsible for seeing that those dirty buffers get written
> out eventually.
You're right.
Vadim
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1999-01-19 06:01:14 | Re: [HACKERS] performance test |
Previous Message | Tom Lane | 1999-01-19 05:25:48 | Re: [HACKERS] Postgres Speed or lack thereof |