Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance

On Tue, Jan 14, 2014 at 1:48 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Jan 14, 2014 at 11:44 AM, James Bottomley
> <James(dot)Bottomley(at)hansenpartnership(dot)com> wrote:
>> No, I'm sorry, that's never going to be possible. No user space
>> application has all the facts. If we give you an interface to force
>> unconditional holding of dirty pages in core you'll livelock the system
>> eventually because you made a wrong decision to hold too many dirty
>> pages. I don't understand why this has to be absolute: if you advise
>> us to hold the pages dirty and we do up until it becomes a choice to
>> hold on to the pages or to thrash the system into a livelock, why would
>> you ever choose the latter? And if, as I'm assuming, you never would,
>> why don't you want the kernel to make that choice for you?
>
> If you don't understand how write-ahead logging works, this
> conversation is going nowhere. Suffice it to say that the word
> "ahead" is not optional.

In essence, if you do flush when you shouldn't, and there is a
hardware failure, or kernel panic, or anything that stops the rest of
the writes from succeeding, your database is kaputt, and you've got to
restore a backup.

Ie: very very bad.