On 2017-12-26 22:30:08 -0800, Robert Haas wrote:
> On Tue, Dec 26, 2017 at 7:51 PM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
> >> > Hmm. What about the case where we try to open a plain file that's on
> >> > an inaccessible filesystem, e.g. due to a disk failure? Allowing
> >> > cancel to work just for FIFOs would be OK, I guess, but allowing it
> >> > for other open() calls that hang would be better. I'm not sure if we
> >> > can make it work that way, but it would be nice if we could.
I doubt it's realistic to make pg resilient in case of FS problems like
that. Partially because the OS level handling usually is very haphazard
and inconsistent, and partially because the amount of work to get there
seems quite significant with only a small payoff.
> >> That is doable, just stat() and check before open().
> >
> > I think TOCTOU when I read such things.. The data folder is a trusted
> > environment but any patches doing things like that ought to be careful.
>
> Yeah. I was more wondering whether an ostensibly non-blocking open()
> would nevertheless block on an inaccessible file.
It very likely would, depending on the type of error. Or stat() would
end up being stuck somewhere in the kernel while it's retrying IO for a
lengthy amount of time.
Greetings,
Andres Freund
