On 1/19/17 11:58 AM, Tom Lane wrote:
> Stephen Frost writes:
>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>>> WFM. Btw, I noticed that BOOTSTRAP_SUPERUSERID is hard-coded as "10"
>>> in this bit in setup_privileges():
>
>> Hm. I seem to recall trying to avoid having the hard-coded value there
>> b
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> WFM. Btw, I noticed that BOOTSTRAP_SUPERUSERID is hard-coded as "10"
> >> in this bit in setup_privileges():
>
> > Hm. I seem to recall trying to avoid having the hard-coded value ther
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> WFM. Btw, I noticed that BOOTSTRAP_SUPERUSERID is hard-coded as "10"
>> in this bit in setup_privileges():
> Hm. I seem to recall trying to avoid having the hard-coded value there
> but we don't have BOOTSTRAP_SUPERUSERID defined
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Peter Eisentraut writes:
> > On 1/19/17 7:53 AM, Tom Lane wrote:
> >> Hm. I see that the patch randomly changed the way that the collation
> >> owner is generated ... looks like it no longer works for mixed-case
> >> usernames. Perhaps follow this model i
Peter Eisentraut writes:
> On 1/19/17 7:53 AM, Tom Lane wrote:
>> Hm. I see that the patch randomly changed the way that the collation
>> owner is generated ... looks like it no longer works for mixed-case
>> usernames. Perhaps follow this model instead:
> We could just use the numeric value, l
On 1/19/17 7:53 AM, Tom Lane wrote:
> Hm. I see that the patch randomly changed the way that the collation
> owner is generated ... looks like it no longer works for mixed-case
> usernames. Perhaps follow this model instead:
>
> if (superuser_password)
> PG_CMD_PRINTF2("ALTER
Amit Kapila writes:
> On Wed, Jan 18, 2017 at 8:06 PM, Peter Eisentraut wrote:
>> Add function to import operating system collations
> After this commit, initdb is failing with below error on one of my VM
> m/c (Linux amitkapila-centos-vm 2.6.32-358.11.1.el6.x86_64):
> performing post-bootstrap
On Wed, Jan 18, 2017 at 8:06 PM, Peter Eisentraut wrote:
> Add function to import operating system collations
>
After this commit, initdb is failing with below error on one of my VM
m/c (Linux amitkapila-centos-vm 2.6.32-358.11.1.el6.x86_64):
./initdb -D ../../data
The files belonging to this d
On 1/18/17 1:46 PM, Tom Lane wrote:
> I wrote:
>> The previous coding applied a sort so as not to depend on what
>> order "locale -a" had returned things in, and I think we need
>> to retain that. At the very least, all the normalized names
>> need to be saved up and entered in a second pass.
>
>
I wrote:
> The previous coding applied a sort so as not to depend on what
> order "locale -a" had returned things in, and I think we need
> to retain that. At the very least, all the normalized names
> need to be saved up and entered in a second pass.
Actually, it seems like doing precisely that
Peter Eisentraut writes:
> OK, the problem has to do with the order of the locale -a output, which
> is in turn dependent on the current locale.
Ah, right, it succeeds unpatched if I run initdb in en_US rather than
C locale.
regards, tom lane
--
Sent via pgsql-committe
Peter Eisentraut writes:
> What's fishy about this is that I can't reproduce it locally in a
> variety of VMs, and the buildfarm is not unanimous either.
Well, as I said, I get
$ locale -a | grep ^aa_ER
aa_ER
aa_ER.utf8
aa_ER.utf8@saaho
aa_ER@saaho
What it looks like to me is that we see "aa_ER
On 1/18/17 12:23 PM, Peter Eisentraut wrote:
> Yeah, it's supposed to do that. Note that the second call to
> CollationCreate() in pg_import_system_collations() has the "if not
> exists" argument true regardless. So the error appears to come from the
> first one.
>
> What's fishy about this is t
On 1/18/17 10:43 AM, Tom Lane wrote:
> Maybe an appropriate fix would be to ignore collations whose names aren't
> equal to what we get for collcollate/collctype. Presumably the latter
> are getting canonicalized somehow.
Yeah, it's supposed to do that. Note that the second call to
CollationCrea
On 18-01-2017 12:43, Tom Lane wrote:
> I wrote:
>> running bootstrap script ... ok
>> performing post-bootstrap initialization ... 2017-01-18 09:49:45.019 EST
>> [25919] FATAL: collation "aa_ER@saaho" for encoding "UTF8" already exists
>> 2017-01-18 09:49:45.019 EST [25919] STATEMENT: SELECT
>>
I wrote:
> running bootstrap script ... ok
> performing post-bootstrap initialization ... 2017-01-18 09:49:45.019 EST
> [25919] FATAL: collation "aa_ER@saaho" for encoding "UTF8" already exists
> 2017-01-18 09:49:45.019 EST [25919] STATEMENT: SELECT
> pg_import_system_collations(if_not_exists =
Peter Eisentraut writes:
> Add function to import operating system collations
The buildfarm's not happy with this, and neither am I:
...
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... 2017-01-18 09:49:45.019 EST
[25919] FATAL: c
Add function to import operating system collations
Move this logic out of initdb into a user-callable function. This
simplifies the code and makes it possible to update the standard
collations later on if additional operating system collations appear.
Reviewed-by: Andres Freund
Reviewed-by: Eul
18 matches
Mail list logo
