On Tue, Jan 14, 2014 at 1:48 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Tue, Jan 14, 2014 at 11:44 AM, James Bottomley
> <james.bottom...@hansenpartnership.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.

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to