Обсуждение: 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