Re: Linux 2.6.6 also

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

In response to

Responses

Browse pgsql-hackers by date

  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