Re: [HACKERS] Postgres Speed or lack thereof - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Postgres Speed or lack thereof
Date
Msg-id 3354.916723548@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Postgres Speed or lack thereof  (Vadim Mikheev <vadim@krs.ru>)
Responses Re: [HACKERS] Postgres Speed or lack thereof
List pgsql-hackers
Vadim Mikheev <vadim@krs.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.

(Of course, errors inside Postgres might cause it to write bogus
data, but -F isn't going to help or hurt for that.)

Not using -F means that you don't trust your OS, your hardware,
and/or your power supply.  It has nothing to do with whether you
trust Postgres.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Vadim Mikheev
Date:
Subject: Re: [HACKERS] performance test
Next
From: Vadim Mikheev
Date:
Subject: Re: [HACKERS] Postgres Speed or lack thereof