Thread: ClosePipeStream failure ignored in pg_import_system_collations
Hackers, I only see three invocations of ClosePipeStream in the sources. In two of them, the return value is checked and an error is raised if it failed. In the third, the error (if any) is squashed. I don't know if a pipe stream over "locale -a" could ever fail to close, but it seems sensible to log an error if it does. Thoughts? mark
Mark Dilger <hornschnorter@gmail.com> writes: > I only see three invocations of ClosePipeStream in the sources. > In two of them, the return value is checked and an error is raised > if it failed. In the third, the error (if any) is squashed. > I don't know if a pipe stream over "locale -a" could ever fail to > close, but it seems sensible to log an error if it does. The concrete case where that's an issue, I think, is that "locale -a" fails, possibly after outputting a few locale names. The only report we get about that is a failure indication from ClosePipeStream. As things stand we just silently push on, creating no or a few collations. With a check, we'd error out ... causing initdb to fail altogether. Maybe that's an overreaction; I'm not sure. Perhaps the right thing is just to issue a warning? But ignoring it completely seems bad. regards, tom lane
On Thu, May 23, 2019 at 3:23 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Mark Dilger <hornschnorter@gmail.com> writes: > > I only see three invocations of ClosePipeStream in the sources. > > In two of them, the return value is checked and an error is raised > > if it failed. In the third, the error (if any) is squashed. > > > I don't know if a pipe stream over "locale -a" could ever fail to > > close, but it seems sensible to log an error if it does. > > The concrete case where that's an issue, I think, is that "locale -a" > fails, possibly after outputting a few locale names. The only report > we get about that is a failure indication from ClosePipeStream. > As things stand we just silently push on, creating no or a few collations. > With a check, we'd error out ... causing initdb to fail altogether. > > Maybe that's an overreaction; I'm not sure. Perhaps the right > thing is just to issue a warning? But ignoring it completely > seems bad. Another option is to retry the "locale -a" call, perhaps after sleeping a short while, but I have no idea how likely a second (or third...) call to "locale -a" is to succeed if the prior call failed, mostly because I don't have a clear idea why it would fail the first time. I would prefer initdb to fail, and fail loudly, rather than warning and moving on, but I can imagine production systems which are set up in a way where that would be painful. Perhaps somebody with such a setup will respond? mark
Mark Dilger <hornschnorter@gmail.com> writes: > On Thu, May 23, 2019 at 3:23 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> The concrete case where that's an issue, I think, is that "locale -a" >> fails, possibly after outputting a few locale names. The only report >> we get about that is a failure indication from ClosePipeStream. >> As things stand we just silently push on, creating no or a few collations. >> With a check, we'd error out ... causing initdb to fail altogether. >> Maybe that's an overreaction; I'm not sure. Perhaps the right >> thing is just to issue a warning? But ignoring it completely >> seems bad. > Another option is to retry the "locale -a" call, perhaps after sleeping > a short while, but I have no idea how likely a second (or third...) call > to "locale -a" is to succeed if the prior call failed, mostly because I > don't have a clear idea why it would fail the first time. I doubt that retrying would be of any value; in a resource-exhaustion situation you might as well just redo the whole initdb. The main case I can think of where you'd get a hard failure is "/usr/bin/locale not installed". I have no idea whether there are any platforms where that would be a likely situation. On my Linux machines it seems to be part of glibc-common, so there's basically 0 chance ... but I can imagine that other platforms with a more stripped-down mentality might allow it to not be present. regards, tom lane