Thread: Re: [HACKERS] [COMMITTERS] pgsql: Add function to import operating system collations

Peter Eisentraut <peter_e@gmx.net> writes:
> Add function to import operating system collations

BTW, hamster's been failing since this went in:

running bootstrap script ... ok
performing post-bootstrap initialization ... 2017-01-19 03:17:38.748 JST [14656] FATAL:  no usable system locales were
found
2017-01-19 03:17:38.748 JST [14656] STATEMENT:  SELECT pg_import_system_collations(if_not_exists => false, schema =>
'pg_catalog');
child process exited with exit code 1

Looking at older reports, I see that it didn't find any system locales
then either, but we did not treat it as a hard error:

running bootstrap script ... ok
performing post-bootstrap initialization ... No usable system locales were found.
Use the option "--debug" to see details.
ok
syncing data to disk ... ok

I have to question the decision to make "no locales" a hard error.
What's the point of that?  In fact, should we even be bothering with
a warning, considering how often initdb runs unattended these days?
        regards, tom lane

On 1/21/17 12:50 PM, Tom Lane wrote:
> I have to question the decision to make "no locales" a hard error.
> What's the point of that?  In fact, should we even be bothering with
> a warning, considering how often initdb runs unattended these days?

Hmm, it was a warning in initdb, so making it an error now is probably a
mistake.  We should change it back to a warning at least.

The reason for the warning originally was to have some output in case
the whole collation initialization fails altogether and does nothing.
For example, at the time, we didn't know how reliable and portable
`locale -a` actually was.  Maybe this didn't actually turn out to be a
problem.

Also, if we add ICU initialization to this, then it's not clear how we
would report if one provider provided zero locales but another did
provide some.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 1/21/17 12:50 PM, Tom Lane wrote:
>> I have to question the decision to make "no locales" a hard error.
>> What's the point of that?  In fact, should we even be bothering with
>> a warning, considering how often initdb runs unattended these days?

> Hmm, it was a warning in initdb, so making it an error now is probably a
> mistake.  We should change it back to a warning at least.

I'd drop it altogether I think ... it was useful debug back in the day
but now I doubt it is worth much.

> Also, if we add ICU initialization to this, then it's not clear how we
> would report if one provider provided zero locales but another did
> provide some.

Would it help to redefine the function as returning the number of locale
entries it successfully added?
        regards, tom lane

On Sun, Jan 22, 2017 at 5:28 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
>> On 1/21/17 12:50 PM, Tom Lane wrote:
>>> I have to question the decision to make "no locales" a hard error.
>>> What's the point of that?  In fact, should we even be bothering with
>>> a warning, considering how often initdb runs unattended these days?
>
>> Hmm, it was a warning in initdb, so making it an error now is probably a
>> mistake.  We should change it back to a warning at least.
>
> I'd drop it altogether I think ... it was useful debug back in the day
> but now I doubt it is worth much.
>
>> Also, if we add ICU initialization to this, then it's not clear how we
>> would report if one provider provided zero locales but another did
>> provide some.
>
> Would it help to redefine the function as returning the number of locale
> entries it successfully added?

It would be nice at least to avoid an error, still even if we decide
to keep it an error I can add a couple of locales in hamster and
dangomushi and we are good to go in the buildfarm. Regarding the
warning, I have found it useful a couple of times on ArchLinux where
no locales are enabled by default.
-- 
Michael

On 1/22/17 3:47 AM, Michael Paquier wrote:
> It would be nice at least to avoid an error, still even if we decide
> to keep it an error I can add a couple of locales in hamster and
> dangomushi and we are good to go in the buildfarm. Regarding the
> warning, I have found it useful a couple of times on ArchLinux where
> no locales are enabled by default.

OK, I just changed it back to a warning.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Tue, Jan 24, 2017 at 3:47 AM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> On 1/22/17 3:47 AM, Michael Paquier wrote:
>> It would be nice at least to avoid an error, still even if we decide
>> to keep it an error I can add a couple of locales in hamster and
>> dangomushi and we are good to go in the buildfarm. Regarding the
>> warning, I have found it useful a couple of times on ArchLinux where
>> no locales are enabled by default.
>
> OK, I just changed it back to a warning.

Thanks.
-- 
Michael