Re: Maximum transaction rate

On Thu, Mar 19, 2009 at 12:49:52AM +0100, Marco Colombo wrote:
> It has to wait for I/O completion on write(), then, it has to go to
> sleep. If two different processes do a write(), you don't know which
> will be awakened first. Preallocation don't mean much here, since with
> O_SYNC you expect a physical write to be done (with the whole sleep/
> HW interrupt/SW interrupt/awake dance). It's true that you may expect
> the writes to be carried out in order, and that might be enough. I'm
> not sure tho.

True, but the relative wakeup order of two different processes is not
important since by definition they are working on different
transactions. As long as the WAL writes for a single transaction (in a
single process) are not reordered you're fine. The benefit of a
non-overwriting storage manager is that you don't need to worry about
undo's. Any incomplete transaction is uncomitted and so any data
produced by that transaction is ignored.

> It may be acceptable or not. Sometimes it's not. Sometimes you must be
> sure the data in on platters before you report "committed". Sometimes
> when you say "fsync!" you mean "i want data flushed to disk NOW, and I
> really mean it!". :)

Ofcourse. Committing a transaction comes down to flipping a single bit.
Before you flip it all the WAL data for that transaction must have hit
disk. And you don't tell the client the transaction has committed until
the fipped bit has hit disk. And fsync better do what you're asking
(how fast is just a performance issue, just as long as it's done).

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.