Scott Ribe <scott_ribe@xxxxxxxxxxxxxxx> 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
