Re: ClosePipeStream failure ignored in pg_import_system_collations

Поиск
Список
Период
Сортировка
От Mark Dilger
Тема Re: ClosePipeStream failure ignored in pg_import_system_collations
Дата
Msg-id CAE-h2To+vEcV_A7mQypDvRjCjwEHP1syf3_ed=jakTaN9+_w9g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: ClosePipeStream failure ignored in pg_import_system_collations  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: ClosePipeStream failure ignored in pg_import_system_collations  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Why could GEQO produce plans with lower costs than the standard_join_search?
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Top-N sorts in EXPLAIN, row count estimates, and parallelism