From: | Manfred Spraul <manfred(at)colorfullife(dot)com> |
---|---|
To: | Gregory Stark <gsstark(at)mit(dot)edu> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Linux 2.6.6 also |
Date: | 2004-05-12 21:32:14 |
Message-ID: | 40A297DE.2070208@colorfullife.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Gregory Stark wrote:
>This patch also looks relevant to Postgres for two reasons.
>
>This part seems like it might expose some bugs that otherwise might have
>remained hidden:
>
> This affects I/O scheduling potentially quite significantly. It is no
> longer the case that the kernel will submit pages for I/O in the order in
> which the application dirtied them. We instead submit them in file-offset
> order all the time.
>
>The part about part-file fdatasync calls seems like could be really useful.
>It seems like that's just speculation about future directions though?
>
>
Correct. The kernel could do that now, but it's not exposed to user space.
But the change highlights one point: the order in which file blocks are
written to disk is undefined. Theoretically the wal checkpoint record
could be on the platter, but the preceeding pages were not written.
Is that case handled by the wal replay code?
--
Manfred
From | Date | Subject | |
---|---|---|---|
Next Message | Bruno Wolff III | 2004-05-12 21:36:14 | Re: Probably security hole in postgresql-7.4.1 |
Previous Message | Tom Lane | 2004-05-12 21:29:55 | Re: Probably security hole in postgresql-7.4.1 |