In the discussion of bug #5599 we pretty much agreed to do this:
> Seems like we need to think harder about recovering from a truncate
> failure. A few random ideas:
> 1. Write the dirty buffers before dropping them. Kind of ugly from a
> performance viewpoint, but simple and safe.
I looked at making this happen, and noted that DropRelFileNodeBuffers
is used both for the truncation case and for dropping relation buffers
during smgrdounlink. In the latter case, it's still appropriate to
drop dirty buffers without writing them, both for performance reasons
and because we don't really care about any errors: we have already
committed the relation DROP, and are not going to look at the file
contents again in any case. So this means that two different behaviors
are now required for truncation and dropping.
The cleanest fix is an API change to add a boolean write-or-not
parameter to DropRelFileNodeBuffers. That's what I want to do in HEAD
and 9.0, but I'm unsure whether it's a safe fix in the back branches.
Does anyone have an opinion whether it's likely that any third-party
code is calling DropRelFileNodeBuffers directly? If there is, then
changing its API in a minor release would be an unfriendly thing to do.
We could avoid that by some ugly expedient like inserting a second copy
of the function in back branches.
Comments?
regards, tom lane