Re: [pgsql-hackers-win32] Sync vs. fsync during checkpoint

On Thursday 05 February 2004 20:24, Tom Lane wrote:
> "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at> writes:
> > So Imho the target should be to have not much IO open for the checkpoint,
> > so the fsync is fast enough, even if serial.
>
> The best we can do is push out dirty pages with write() via the bgwriter
> and hope that the kernel will see fit to write them before checkpoint
> time arrives. I am not sure if that hope has basis in fact or if it's
> just wishful thinking. Most likely, if it does have basis in fact it's
> because there is a standard syncer daemon forcing a sync() every thirty
> seconds.

There are other benefits of writing pages earlier even though they might not
get synced immediately.

It would tell kernel that this is latest copy of updated buffer. Kernel VFS
should make that copy visible to every other backend as well. The buffer
manager will fetch the updated copy from VFS cache next time. All without
going to disk actually..(Within the 30 seconds window of course..)

> People keep saying that the bgwriter mustn't write pages synchronously
> because it'd be bad for performance, but I think that analysis is
> faulty. Performance of what --- the bgwriter? Nonsense, the *point*
> of the bgwriter is to do the slow tasks. The only argument that has
> any merit is that O_SYNC or immediate fsync will prevent us from having
> multiple writes outstanding and thus reduce the efficiency of disk
> write scheduling. This is a valid point but there is a limit to how
> many writes we need to have in flight to keep things flowing smoothly.

Is it a valid assumption for platforms-that-postgresql-supports that a write
call would make changes visible across processes?
>
> What I'm thinking now is that the bgwriter should issue frequent fsyncs
> for its writes --- not immediate, but a lot more often than once per

frequent fsyncs or frequent fsyncs per file descriptor written? I thought it
was later.

Just a thought.

Shridhar