Thomas Munro <thomas.munro@enterprisedb.com> writes:
>>> Really? The specification says that it starts I/O, not that it waits
>>> around for any to finish.
> Right, there was some discussion of that, and I didn't (and still
> don't) think it'd be wise to rely on undocumented knowledge about
> which flags can eat errors based on a drive-by reading of a particular
> snapshot of the Linux tree. The man page says it can return EIO; I
> think we should assume that it might actually do that.
I had a thought about this: maybe we should restrict the scope of this
behavior to be "panic on EIO", not "panic on anything within hailing
distance of fsync".
The direction you and Andres seem to want to go in is to add a pile of
unprincipled exception cases, which seems like a recipe for constant
pain to me. I think we might be better off with a whitelist of errnos
that mean trouble, instead of a blacklist of some that don't. I'm
especially troubled by the idea that blacklisting some errnos might
reduce to ignoring them completely, which would be a step backwards
from our pre-PANIC behavior.
regards, tom lane