On Wed, Mar 18, 2009 at 10:58:39PM +0100, Marco Colombo wrote:
> I hope it's "full defence". If you have two processes doing at the
> same time write(); fsycn(); on the same file, either there are no order
> requirements, or it will boom sooner or later... fsync() works inside
> a single process, but any system call may put the process to sleep, and
> who knows when it will be awakened and what other processes did to that
> file meanwhile. I'm pretty confident that PG code protects access to
> shared resources with synchronization primitives.
Generally PG uses O_SYNC on open, so it's only one system call, not
two. And the file it's writing to is generally preallocated (not
always though).
> Well, that's highly dependant on your expectations :) I don't expect
> a fsync to trigger a journal commit, if metadata hasn't changed. That's
> obviuosly true for metadata-only journals (like most of them, with
> notable exceptions of ext3 in data=journal mode).
Really the only thing needed is that the WAL entry reaches disk before
the actual data does. AIUI as long as you have that the situation is
recoverable. Given that the actual data probably won't be written for a
while it'd need to go pretty wonky before you see an issue.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.
