From: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
---|---|
To: | Shridhar Daithankar <shridhar_daithankar(at)myrealbox(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Background writer process |
Date: | 2003-11-14 16:40:38 |
Message-ID: | 3FB50586.8040401@Yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Shridhar Daithankar wrote:
> On Friday 14 November 2003 03:05, Jan Wieck wrote:
>> For sure the sync() needs to be replaced by the discussed fsync() of
>> recently written files. And I think the algorithm how much and how often
>> to flush can be significantly improved. But after all, this does not
>> change the real checkpointing at all, and the general framework having a
>> separate process is what we probably want.
>
> Having fsync for regular data files and sync for WAL segment a comfortable
> compramise? Or this is going to use fsync for all of them.
>
> IMO, with fsync, we tell kernel that you can write this buffer. It may or may
> not write it immediately, unless it is hard sync.
I think it's more the other way around. On some systems sync() might
return before all buffers are flushed to disk, while fsync() does not.
>
> Since postgresql can afford lazy writes for data files, I think this could
> work.
The whole point of a checkpoint is to know for certain that a specific
change is in the datafile, so that it is safe to throw away older WAL
segments.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-11-14 16:43:38 | Re: heads up -- subtle change of behavior of new initdb |
Previous Message | Tom Lane | 2003-11-14 16:38:20 | Re: ALTER TABLE modifications |