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: http://www.postgresql.org/mailpref/pgsql-hackers
