Bug#340166: Crossgrade from postgresql 7.4 to postgresql-7.4 broke DATADIR environment variables
Hi, Martin, Martin Pitt wrote: >>I used to have this setting in the init.d scripts, but as an apt-get >>upgrade overwrote this file, I was told to use postmaster.env instead. I >>don't remember whether there was an official bug filing, or this was >>private email. > > I did never see that bug, so maybe it was in a private email to Oliver > Elphick? Well, I searched my mail archive, and it was a side discussion in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=284364 I also mis-remembered: It was postmaster.conf that was advised, and this is what we used on most machines. I don't know where the .env slipped in. >>As a workaround until all 7.4 databases are migrated, I just want to >>know the right place where to hack in this environment variable, so the >>postmaster process can access it. > > As far as I can see, an equivalent to the old postgresql.env file > seems to make sense and would also offer a transition path for the old > /etc/postgresql/postgresql.env file. So if postgresql-common would > support /etc/postgresql/version/cluster/environment, then you could > add these variables there, and the transitional postgresql package > could move postgresql.env there. > > Do you agree? Yes, this would solve my problem. Thanks, Markus signature.asc Description: OpenPGP digital signature
Bug#340166: Crossgrade from postgresql 7.4 to postgresql-7.4 broke DATADIR environment variables
Hi Markus! Markus Schaber [2006-01-01 12:03 +0100]: > http://www.postgresql.org/docs/7.4/interactive/manage-ag-alternate-locs.html > documents this behaviour. Ah, I see. Thank you. > >>Not only that the environment variable setting was not migrated, I also > >>did not find the right place to reinstantiate this setting. > > > > I see, so you defined PGDATAEXTERN in postgresql.env? What does this > > variable do? It is not documented anywhere and not present in the > > default postgresql.env or postmaster.conf files. > > Yes, I defined it in postgresql.env, and then used it in "createdb > --location=PGDATAEXTERN" when creating the database. > > I used to have this setting in the init.d scripts, but as an apt-get > upgrade overwrote this file, I was told to use postmaster.env instead. I > don't remember whether there was an official bug filing, or this was > private email. I did never see that bug, so maybe it was in a private email to Oliver Elphick? > As a workaround until all 7.4 databases are migrated, I just want to > know the right place where to hack in this environment variable, so the > postmaster process can access it. As far as I can see, an equivalent to the old postgresql.env file seems to make sense and would also offer a transition path for the old /etc/postgresql/postgresql.env file. So if postgresql-common would support /etc/postgresql/version/cluster/environment, then you could add these variables there, and the transitional postgresql package could move postgresql.env there. Do you agree? Thanks, Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org In a world without walls and fences, who needs Windows and Gates? signature.asc Description: Digital signature
Bug#340166: Crossgrade from postgresql 7.4 to postgresql-7.4 broke DATADIR environment variables
Hi, Martin, Martin Pitt schrieb: >>In the earlier postgresql instalations, one could define environment >>variables in postgresql.env or postmaster.conf which then were exported >>to the postmaster, and we could use it as LOCATION when creating new >>databases in other locations. > > These files are obsolete and ignored in the new infrastructure. The > current way to move the data directory around is to just do it and > correct the /etc/postgresql/7.4/main/pgdata symlink. It is not about the main cluster data directory. It's a kind of "poor mens tablespace" where one could create a database in a different directory than its cluster. http://www.postgresql.org/docs/7.4/interactive/manage-ag-alternate-locs.html documents this behaviour. >>dropdb: database removal failed: ERROR: postmaster environment variable >>"PGDATAEXTERN" not found >>Not only that the environment variable setting was not migrated, I also >>did not find the right place to reinstantiate this setting. > > I see, so you defined PGDATAEXTERN in postgresql.env? What does this > variable do? It is not documented anywhere and not present in the > default postgresql.env or postmaster.conf files. Yes, I defined it in postgresql.env, and then used it in "createdb --location=PGDATAEXTERN" when creating the database. I used to have this setting in the init.d scripts, but as an apt-get upgrade overwrote this file, I was told to use postmaster.env instead. I don't remember whether there was an official bug filing, or this was private email. > I need further information about what you want to do to be able to do > something about this bug. As a workaround until all 7.4 databases are migrated, I just want to know the right place where to hack in this environment variable, so the postmaster process can access it. It is interesting that normal database access works, only some commands like drop database seem to use the environment variable actually. >>So I'm stuck with either dropping the whole cluster (and thus having to >>migrate about 50 gig into a new cluster without stopping production >>environment), or having an empty zombie-database lingering around which >>confuses users. > > I don't understand; if you have a proper data directory somewhere, you > can always integrate it in the Debian infrastructure with > pg_createcluster -d /path/to/data/directory. Can you please elaborate > about what the problem is? The problem is that the main data directory for the cluster was properly migrated (and is the 7.4/main cluster now), but not the database specific directory. > Thank you, and 'guten Rutsch'! Its me who has to say "Thank you". Ebenfalls einen guten Rutsch und ein erfolgreiches neues Jahr. Markus signature.asc Description: OpenPGP digital signature
Bug#340166: Crossgrade from postgresql 7.4 to postgresql-7.4 broke DATADIR environment variables
tag 340166 moreinfo thanks Hi Markus! Markus Schaber [2005-11-21 14:40 +0100]: > In the earlier postgresql instalations, one could define environment > variables in postgresql.env or postmaster.conf which then were exported > to the postmaster, and we could use it as LOCATION when creating new > databases in other locations. These files are obsolete and ignored in the new infrastructure. The current way to move the data directory around is to just do it and correct the /etc/postgresql/7.4/main/pgdata symlink. > dropdb: database removal failed: ERROR: postmaster environment variable > "PGDATAEXTERN" not found > > Not only that the environment variable setting was not migrated, I also > did not find the right place to reinstantiate this setting. I see, so you defined PGDATAEXTERN in postgresql.env? What does this variable do? It is not documented anywhere and not present in the default postgresql.env or postmaster.conf files. I need further information about what you want to do to be able to do something about this bug. > So I'm stuck with either dropping the whole cluster (and thus having to > migrate about 50 gig into a new cluster without stopping production > environment), or having an empty zombie-database lingering around which > confuses users. I don't understand; if you have a proper data directory somewhere, you can always integrate it in the Debian infrastructure with pg_createcluster -d /path/to/data/directory. Can you please elaborate about what the problem is? Thank you, and 'guten Rutsch'! Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org In a world without walls and fences, who needs Windows and Gates? signature.asc Description: Digital signature
Bug#340166: Crossgrade from postgresql 7.4 to postgresql-7.4 broke DATADIR environment variables
Package: postgresql-7.4 Version: 1:7.4.8-17 Severity: normal Hi, Some time ago, I "crossgraded" the Postgresql 7.4 installation to the new postgresql-common and postgresql-7.4 packaging. In the earlier postgresql instalations, one could define environment variables in postgresql.env or postmaster.conf which then were exported to the postmaster, and we could use it as LOCATION when creating new databases in other locations. I happen to have such legacy databases, and recently wanted to drop one of them, and got the following error message: dropdb: database removal failed: ERROR: postmaster environment variable "PGDATAEXTERN" not found Not only that the environment variable setting was not migrated, I also did not find the right place to reinstantiate this setting. All the init scripts seem to be generic for the different postgresql versions, and the postmaster itsself is a binary... So I'm stuck with either dropping the whole cluster (and thus having to migrate about 50 gig into a new cluster without stopping production environment), or having an empty zombie-database lingering around which confuses users. Thanks, Markus -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14.1 Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages postgresql-7.4 depends on: ii libc6 2.3.5-6GNU C Library: Shared libraries an ii libcomerr21.38-2 common error description library ii libkrb53 1.3.6-5MIT Kerberos runtime libraries ii libpam0g 0.79-3 Pluggable Authentication Modules l ii libpq31:7.4.8-17 PostgreSQL C client library ii libreadline5 5.0-11 GNU readline and history libraries ii libssl0.9.7 0.9.7g-5 SSL shared libraries ii postgresql-client-7.4 1:7.4.8-17 front-end programs for PostgreSQL ii postgresql-common 32 manager for PostgreSQL database cl ii zlib1g1:1.2.3-4 compression library - runtime postgresql-7.4 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]