Re: simplify register_dirty_segment()

[Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>]

"Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu> writes:
> I can't figure out why it tooks so long time in windows and SunOS for clean
> files -

I told you why: they don't maintain bookkeeping information that allows
them to quickly identify dirty buffers belonging to a particular file.
Linux does ... but I'm not sure that makes it "smarter", since that
bookkeeping has a distributed cost, and the cost might or might not
be repaid in any particular system workload.  It would be a reasonable
bet for a kernel designer to assume that fsync() is generally going to
have to wait for some I/O and so a bit of CPU overhead isn't really
going to matter.

> You are right. A possible (but not clean) solution is like this: The
> bgwriter maintain a refcount for each file. When the file is open,
> refcount++, when the file is closing, refcount--. When the refcount goes to
> zero, Bgwriter could safely remove it from its PendingOpsTable after
> checkpoint.

Adjusting such a global refcount would require global locks, which is
just what you were hoping to avoid :-(

			regards, tom lane