Scott Ribe <scott_ribe@killerbytes.com> writes:
> Note when it happens, and if it doesn't succeed for some value of "too
> long", at least escalate to ERROR message, possibly fail.
ERROR and "fail" are the same thing. We could do this, and it wouldn't
even be much code, but it doesn't seem to address the problem real well:
1. It's still the case that if we let the checkpoint complete, and then
the system crashes before the file's actually been flushed to disk,
you'd lose data. Putting a limit on the time we let this state persist
doesn't seem to me to accomplish a lot, mainly because it's hardly
credible that the system wouldn't have sync'd the data of its own accord
before the timeout. (The place where we have this problem is *not*
trying to write data out to the kernel; it's trying to be sure that the
kernel has pushed previously-written data down to disk. I do not know
Windows' exact policies for that, but I seriously doubt they let dirty
disk buffers sit around indefinitely.)
2. It'd certainly be useful if we could alert the DBA that something is
interfering with access to our disk files, but having the bgwriter log a
message in the postmaster log that says ERROR rather than only LOG is
probably not going to draw the average Windows user's attention :-(
regards, tom lane