(This is a bug related to the resolution of bug 49864, i have added the same comments there) Passing the PGDATA or/and PG_INITDB_OPTS to emerge --config doesn't work as expected. If you intsall the package and then set any or both variables and try to emerge --config postgres, the script will always tell you that PG_INITDB_OPTS is "" and PGDATA is /var/lib/.... (the default) We have tried to set the variables via export, env.d, direct on the command line, etc ... After taking a look into the package environment file we noticed that the variables are not there, whatever we do. Apparently both environment variables MUST be set BEFORE EMERGING the package (???), then the variables also appear in the package environment file. Don't know if this is an issue only with this package (8.3.3 ebuild) or with portage itself. Reproducible: Always Steps to Reproduce: 1. Make sure your environment DOESN'T have PGDATA or PG_INITDB_OPTS 2.EMERGE postgresql-server 8.3.3 (we only tested that one, but i think the other ebuilds will show the same behavior) 3. Set PGDATA and/or PG_INITDB_OPTS to the value you need (eg. -E UTF8 for opts) 4. try emerge --config 5. watch the results 6. set the environment for ALL & ANY user in the system 7. check the environment to make sure the variables are set 8. repeat 4 - 8 until you have no more ideas how to set the environment (9. optional .... jump out the window) Setting the variables to values desired and then REEMERGING the ebuild changes the default values for emerge --config to the values of the variables, thus this can be used as a temporary "fix" . Alternatively, don't use emerge --config, do the steps manually ....
I can confirm this behaviour for postgresql-server-8.3.4 very confusing at first, until i read this bug report here
I worked around it by editing /var/db/pkg/dev-db/postgresql-server-$VERSION/environment.bz2 Still quite annoying, most users would probably give up and `initdb` themselves, losing the extra emerge checks.
The same thing happens with postgresql-server-8.3.5
Why not using it from /etc/conf.d/postgresql?
Still applicable to 8.3.7
I can confirm this issue still happens on 8.3.7
I'm bitten by this on postgresql-server-8.4.1 as well
same here.. cuz i'm lazy I added a file to /etc/profile.d/ called postgres_pginitdb.sh with my options in my case it just contains this line: export PG_INITDB_OPTS=" -E UTF8 " then env-update && source /etc/profile re-emerge postgresql-server and - if like me you only want your dbs in utf8 never worry about it again ..
please remove this confusing lines from instalation messages: * You can pass options to initdb by setting the PG_INITDB_OPTS variable. * ... * Simply add the options you would have added to initdb to the PG_INITDB_OPTS variable. * it is definitely not true
Created attachment 213469 [details] ebuild to take /etc/conf.d/postgresql-SLOT into account This ebuild to take /etc/conf.d/postgresql-${SLOT} into account, giving an obvious place to set the variables. --- /usr/portage/dev-db/postgresql-server/postgresql-server-8.4.2.ebuild 2009-12-14 18:57:33.000000000 +0000 +++ /usr/local/portage/dev-db/postgresql-server/postgresql-server-8.4.2.ebuild 2009-12-19 12:15:07.000000000 +0000 @@ -150,9 +150,10 @@ } pkg_config() { + [[ -e /etc/conf.d/postgresql-${SLOT} ]] && source /etc/conf.d/postgresql-${SLOT} [[ -z "${PGDATA}" ]] && PGDATA="/var/lib/postgresql/${SLOT}/data" - einfo "You can pass options to initdb by setting the PG_INITDB_OPTS variable." + einfo "You can pass options to initdb by setting the PGDATA and PG_INITDB_OPTS variable in /etc/conf.d/postgresql-${SLOT}." einfo "More information can be found here:" einfo " http://www.postgresql.org/docs/${SLOT}/static/creating-cluster.html" einfo " http://www.postgresql.org/docs/${SLOT}/static/app-initdb.html"
Created attachment 213471 [details] conf.d file adding PG_INITDB_OPTS A complement to the previous attachment, add the PG_INITDB_OPTS variable to the conf.d file. --- /usr/portage/dev-db/postgresql-server/files/postgresql.conf-8.4 2009-09-09 22:41:25.000000000 +0100 +++ /usr/local/portage/dev-db/postgresql-server/files/postgresql.conf-8.4 2009-12-19 12:48:05.000000000 +0000 @@ -1,6 +1,9 @@ # PostgreSQL's Database Directory PGDATA="/var/lib/postgresql/8.4/data" +# Initdb options for emerge --config +PG_INITDB_OPTS="" + # PostgreSQL User PGUSER="postgres"
I can confirm that the fixes in #10 and #11 worked for me. Any idea when this can be committed to portage?
Given that I first reported this as a problem in March of 2008, and provided a fix at the time which was never implemented (see http://bugs.gentoo.org/show_bug.cgi?id=214438), I wouldn't hold your breath!
Any reason why the fix for this bug is not being commited to portage?
This should be fixed with the last bump.
and what bump is that? 8.4.2-r1? not that I can tell.
The bumps 8.3.10 and 8.4.3 have the fix. Thanks for the update :) But the ebuild now forces me to set "--locale=foobar" in PG_INITDB_OPTS. That's annoying because I'm not interested about setting the locale, I'm only interested in the encoding (or rather, my system locale suit me fine). I do not have a /etc/env.d/02locale file. Clients that rely on a specific server locale would do much better to set the locale at connection time anyway. The ebuild error message "No locale information found or character set not specified." is wrong, since I did specify a character set. Could the ebuild be changed so I'm allowed to simply state PG_INITDB_OPTS="-E utf8" ? Or are you saying that ommiting an explicit "--locale=foobar" is a bad idea (Why ?) ?
This is still an issue in the latest postgresql. There is no clear explanation of what needs to be set in PG_INITDB_OPTS. I am at a loss as to what to do to get the config to work. This used to Just Work (TM). What gives?
(In reply to comment #18) > This is still an issue in the latest postgresql. > > There is no clear explanation of what needs to be set in PG_INITDB_OPTS. I am > at a loss as to what to do to get the config to work. This used to Just Work > (TM). What gives? > There are some updated confs that didn't get committed, and I also forgot to add instructions in the post-emerge output to edit /etc/conf.d/postgresql-${SLOT}. For the moment: http://en.gentoo-wiki.com/wiki/PostgreSQL
(In reply to comment #17) > The bumps 8.3.10 and 8.4.3 have the fix. Thanks for the update :) > > But the ebuild now forces me to set "--locale=foobar" in PG_INITDB_OPTS. That's > annoying because I'm not interested about setting the locale, I'm only > interested in the encoding (or rather, my system locale suit me fine). I do not > have a /etc/env.d/02locale file. Clients that rely on a specific server locale > would do much better to set the locale at connection time anyway. > > > Could the ebuild be changed so I'm allowed to simply state PG_INITDB_OPTS="-E > utf8" ? Or are you saying that ommiting an explicit "--locale=foobar" is a bad > idea (Why ?) ? > There are two locales variables that are set by intitdb that cannot be changed later without deleting the entire data directory and starting over. Forcing users to explicitly state the default locale may seem a bit heavy handed, but it ensures that the user gets what they expect. Setting the default locale should not override a client's request for a different locale's language and ordering provided that you've enabled NLS. Bear in mind, it's just a default in such case that a client hasn't requested a different locale setting, which if the clients expect a different locale, then they should set it at connection time anyway. The ebuilds will accept C or POSIX as a valid locale if you want PostgreSQL to be locale-less; '--locale=C' or '--locale=POSIX'. You may continue using the -E option if you wish, or you could tack it on to the the locale option; '--locale=C.UTF-8' or '--locale=POSIX.UTF-8'. --locale is the default setting across the board. --locale can be overridden by any of the other --lc options for their respective categories. > The ebuild error message "No locale information found or character set not > specified." is wrong, since I did specify a character set. Read it again. One, the other or both are not satisfied. The sentence is correct as you haven't specified a locale, hence "No locale information found...."
(In reply to comment #16) > and what bump is that? 8.4.2-r1? not that I can tell. > 7.4.28, 8.0.24, 8.1.20, 8.2.16, 8.3.10 and 8.4.3.
(In reply to comment #20) > (In reply to comment #17) > There are two locales variables that are set by intitdb that cannot be changed > later without deleting the entire data directory and starting over. Forcing > users to explicitly state the default locale may seem a bit heavy handed, but > it ensures that the user gets what they expect. I'm intrigued, what locale (not encoding) variable cannot be set at runtime ? > Setting the default locale should not override a client's request for a > different locale's language and ordering provided that you've enabled NLS. Bear > in mind, it's just a default in such case that a client hasn't requested a > different locale setting, which if the clients expect a different locale, then > they should set it at connection time anyway. Indeed, all clients can (and really really should) override locale settings they rely on. Encoding cannot be changed at runtime, however (I'm not aware of any locale-dependant behaviour that has this restriction). That is why I care about encoding but not about locale. As a hint that postgresql developers agree with me, encoding has short and long options, whereas locale only has a long option. That's why I frown at the ebuild's heavy-handed "suggestion" to explicitly set the locale. However, I can live with it. I suppose it's better to annoy folks during initdb than to let some of them be surprised 500GB of data later :) > > The ebuild error message "No locale information found or character set not > > specified." is wrong, since I did specify a character set. > Read it again. One, the other or both are not satisfied. The sentence is > correct as you haven't specified a locale, hence "No locale information > found...." I read it again, and it can be interpreted both ways in english : either "(problem A) or (problem B)" or "problem (A or B)". It may sound subtle, but I suggest adding a coma after "found" to make it clear you mean the first interpretation.
(In reply to comment #22) > (In reply to comment #20) > > (In reply to comment #17) > > There are two locales variables that are set by intitdb that cannot be changed > > later without deleting the entire data directory and starting over. Forcing > > users to explicitly state the default locale may seem a bit heavy handed, but > > it ensures that the user gets what they expect. > > I'm intrigued, what locale (not encoding) variable cannot be set at runtime ? LC_COLLATE and LC_CTYPE cannot be changed after they're set. And I was mistaken, once it's set on a database, not the entire cluster, it can't be changed without dropping the database and starting over whereas the other four categories can be changed "on-the-fly." (Although, in some cases, dropping the database is almost the equivalent of deleting the data directory.) > > Setting the default locale should not override a client's request for a > > different locale's language and ordering provided that you've enabled NLS. Bear > > in mind, it's just a default in such case that a client hasn't requested a > > different locale setting, which if the clients expect a different locale, then > > they should set it at connection time anyway. > > Indeed, all clients can (and really really should) override locale settings > they rely on. Encoding cannot be changed at runtime, however (I'm not aware of > any locale-dependant behaviour that has this restriction). That is why I care > about encoding but not about locale. As a hint that postgresql developers agree > with me, encoding has short and long options, whereas locale only has a long > option. > > That's why I frown at the ebuild's heavy-handed "suggestion" to explicitly set > the locale. However, I can live with it. I suppose it's better to annoy folks > during initdb than to let some of them be surprised 500GB of data later :) Actually, the PostgreSQL developers are just following the standard for defining the locale as they do for defining the encoding. The encoding for a database can deviate from the default, just as the locale can, at database creation time, which again can only be changed by dropping the database and starting over if a different encoding is desired. For locale dependent behavior: LC_COLLATE determines the string sort order, such as ORDER BY, and LC_CTYPE describes what a character is for upper and lower case equivalents or otherwise, such as the upper, lower and initcap functions. Additionally, initdb will, if not provided the --locale argument, resort to grabbing the locale from the system. A user that has multiple locales set for his or her system, as is quite often the case if C and POSIX are included as "locales", that user cannot rely on initdb to select a reasonable default locale and encoding as initdb will grab en_US or other equivalent instead of using C or POSIX if one of those were actually the desired locale. The documentation is not clear as to which locale is given precedence for more than the three, but -- as has been clearly shown -- en_US is preferred over C or POSIX. After considering all that, what seemed to be heavy-handed is actually quite reasonable as the user is ensured to get the defaults that he or she desires, which is the Gentoo way.
(In reply to comment #23) > (In reply to comment #22) > > (In reply to comment #20) > > I'm intrigued, what locale (not encoding) variable cannot be set at runtime ? > > LC_COLLATE and LC_CTYPE cannot be changed after they're set. And I was > mistaken, once it's set on a database, not the entire cluster, it can't be > changed without dropping the database and starting over whereas the other four > categories can be changed "on-the-fly." (Although, in some cases, dropping the > database is almost the equivalent of deleting the data directory.) I stand corrected, and should have RTFM. Thanks for the explanation and the ebuild; I'll now stop treating this bug as a mailing-list.
I still can't configure postgresql-server 8.4.3. I didn't understand EXACTLY the problem described in this bug, I didn't get if the package STILL needs to be configured before first emerging it, but I have 02locale configured, and still emerge --config don't finish cleanly, I don't have my PGSQL cluster initialized. My 02locale: $ cat /etc/env.d/02locale LANG="en_US" LC_CTYPE="pt_BR" LC_NUMERIC="pt_BR" LC_TIME="pt_BR" LC_COLLATE="pt_BR" LC_MONETARY="pt_BR" LC_MESSAGES="en_US" LC_PAPER="pt_BR" LC_NAME="pt_BR" LC_ADDRESS="pt_BR" LC_TELEPHONE="pt_BR" LC_MEASUREMENT="pt_BR" LC_IDENTIFICATION="pt_BR" I understand I don't need to change /etc/conf.d/postgresql-8.4, since my 02locale is sufficient. At least that's what the ebuild tells me. I've tried to change the ebuild to output PG_INITDB_OPTS, but without success. I think the problem in my case is that the ebuild doesn't correctly interpret my 02locale, but even adding PG_INITDB_OPTS on /etc/conf.d/postgresql-8.4 don't work.
(In reply to comment #25) After I set PG_INITDB_OPTS="--locale=en_US.UTF-8" in /etc/conf.d/postgresql-8.4 it worked for me.
(In reply to comment #25) You lack the character encoding at the end; lo_LO.ENC. I've rewritten the ebuilds so the behavior should be quite a bit better. Just need to make sure it works right yet.
