Re: ClosePipeStream failure ignored in pg_import_system_collations
От | Tom Lane |
---|---|
Тема | Re: ClosePipeStream failure ignored in pg_import_system_collations |
Дата | |
Msg-id | 1688.1558651519@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: ClosePipeStream failure ignored in pg_import_system_collations (Mark Dilger <hornschnorter@gmail.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: