Search Postgresql Archives

Re: fdatasync performance problem with large number of DB files

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Michael Brown <michael.brown@xxxxxxxxxxxxx> writes:
> I presume the reason postgres doesn't blindly run a sync() is that we
> don't know what other I/O is on the system and it'd be rude to affect
> other services. That makes sense, except for our environment the work
> done by the recursive fsync is orders of magnitude more disruptive than
> a sync().

Hmm.

> * is there a knob missing we can configure?

No.  The trouble with sync() is that per POSIX, it only schedules the
writes; there's no way to tell when the work has been done.  I see
that Linux offers stronger promises in this department, but I don't
think that's very portable.  Moreover, even on Linux there's no
way to detect whether any of the writes failed.

Barring some solution to those problems, we would be unlikely to take
a patch that uses sync() instead of fsync().

			regards, tom lane





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux