Bug#598447: postgresql-9.0: provide a usable way of upgrade from previous 8.4 server

2010-09-29 Thread Martin Pitt
Hello Rene,

SkyRaT [2010-09-29  2:31 +0200]:
 While having a previous 8.4 version of server installed and running, it
 is impossible to install the package at all (automatic way).
 
 Both services use the same 5432 TCP/IP port and so the second one fails
 to start.

How did you install 9.0? postgresql-common's pg_createcluster usually
picks the next free port, so in normal setups this just works, and
an apt-get install p-9.0 in this situation should end up on port 5433.
What does pg_lsclusters say for you?

 I do not remember such behavior while upgrading 8.3 - 8.4. There was
 something like auto-switch-to-next-port-available feature.

Yes, and this didn't change. It is possible that the port
configuration for your 8.4 cluster perhaps changed in a particular way
which pg_createcluster can't detect? Perhaps you can attach your
/etc/postgresql/8.4/main/postgresql.conf?

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#598447: postgresql-9.0: provide a usable way of upgrade from previous 8.4 server

2010-09-29 Thread SkyRaT
Hi Martin,

 
 How did you install 9.0? postgresql-common's pg_createcluster usually
 picks the next free port, so in normal setups this just works, and
 an apt-get install p-9.0 in this situation should end up on port 5433.
 What does pg_lsclusters say for you?

Aptitude automatically marked the meta-package postgresql as upgradeable and 
so installed all 9.0 related packages and upgraded the postgresql-common to 
version 111. So maybe wrong order of installing these packages??? The 8.4 
remained installed which is definitely correct. All was done automatically, I 
just checked the preview, what will it install/upgrade and it was perfectly ok.

I don't have 8.4 anymore, so pg_lsclusters shows only:
9.0 main 5432 online .

 
  I do not remember such behavior while upgrading 8.3 - 8.4. There was
  something like auto-switch-to-next-port-available feature.
 
 Yes, and this didn't change. It is possible that the port
 configuration for your 8.4 cluster perhaps changed in a particular way
 which pg_createcluster can't detect? Perhaps you can attach your
 /etc/postgresql/8.4/main/postgresql.conf?

I'm definitely sure both services were configured to the same port number 
(5432) - I had to fix that manually to get the 9.0 installed.

Can you try to reproduce the problem? I can also try again...

I also think, a part of the solution generally is to get the postinst script in 
the package NOT depend on a successful execution of the service. Of course it 
should throw a BIG-FAT-WARNING, that the service was unable to start, but 
should not fail with the installation.

Cheers,
  Rene



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#598447: postgresql-9.0: provide a usable way of upgrade from previous 8.4 server

2010-09-29 Thread Martin Pitt
Hello Rene,

SkyRaT [2010-09-29 12:11 +0200]:
 Aptitude automatically marked the meta-package postgresql as
 upgradeable and so installed all 9.0 related packages and upgraded
 the postgresql-common to version 111. So maybe wrong order of
 installing these packages??? 

No, this sounds fine.

 Can you try to reproduce the problem? I can also try again...

I'm doing this all the time, and the test suite does a lot of that. As
I said, the problem might lay in a particular way of configuring the
ports, only listening to particular interfaces, not having an Unix
socket or having it in a wrong directory, etc. Therefore it is not
easy to reproduce, and thus I asked for your postgresql.conf.

 I also think, a part of the solution generally is to get the
 postinst script in the package NOT depend on a successful execution
 of the service. Of course it should throw a BIG-FAT-WARNING, that
 the service was unable to start, but should not fail with the
 installation.

That's the current standard practice of Debian packages, though.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#598447: postgresql-9.0: provide a usable way of upgrade from previous 8.4 server

2010-09-29 Thread Julian Mehnle
For the record, it worked fine when I just installed the 9.0 packages:

$ sudo aptitude
[selected packages in UI]
Reading changelogs... Done
apt-listchanges: Do you want to continue? [Y/n]
Preconfiguring packages ...
(Reading database ... 149860 files and directories currently installed.)
Preparing to replace libpq5 8.4.2-2+b1 (using .../libpq5_9.0.0-3_amd64.deb) 
...
Unpacking replacement libpq5 ...
Preparing to replace postgresql-client-common 110 (using 
.../postgresql-client-common_111_all.deb) ...
Unpacking replacement postgresql-client-common ...
Selecting previously deselected package postgresql-client-9.0.
Unpacking postgresql-client-9.0 (from 
.../postgresql-client-9.0_9.0.0-3_amd64.deb) ...
Preparing to replace postgresql-common 110 (using 
.../postgresql-common_111_all.deb) ...
Stopping PostgreSQL 8.4 database server: main.
Fixing init script priority of /etc/rc2.d/S20postgresql to S19...
Fixing init script priority of /etc/rc3.d/S20postgresql to S19...
Fixing init script priority of /etc/rc4.d/S20postgresql to S19...
Fixing init script priority of /etc/rc5.d/S20postgresql to S19...
Fixing init script priority of /etc/rc0.d/K20postgresql to K21...
Fixing init script priority of /etc/rc1.d/K20postgresql to K21...
Fixing init script priority of /etc/rc6.d/K20postgresql to K21...
Unpacking replacement postgresql-common ...
Selecting previously deselected package postgresql-9.0.
Unpacking postgresql-9.0 (from .../postgresql-9.0_9.0.0-3_amd64.deb) ...
Preparing to replace postgresql 8.4.4-2 (using 
.../postgresql_9.0.0-3_all.deb) ...
Unpacking replacement postgresql ...
Preparing to replace postgresql-client 8.4.4-2 (using 
.../postgresql-client_9.0.0-3_all.deb) ...
Unpacking replacement postgresql-client ...
Selecting previously deselected package postgresql-contrib-9.0.
Unpacking postgresql-contrib-9.0 (from 
.../postgresql-contrib-9.0_9.0.0-3_amd64.deb) ...
Preparing to replace postgresql-contrib 8.4.4-2 (using 
.../postgresql-contrib_9.0.0-3_all.deb) ...
Unpacking replacement postgresql-contrib ...
Selecting previously deselected package postgresql-plperl-9.0.
Unpacking postgresql-plperl-9.0 (from 
.../postgresql-plperl-9.0_9.0.0-3_amd64.deb) ...
Selecting previously deselected package postgresql-plpython-9.0.
Unpacking postgresql-plpython-9.0 (from 
.../postgresql-plpython-9.0_9.0.0-3_amd64.deb) ...
Processing triggers for man-db ...
Setting up libpq5 (9.0.0-3) ...
Setting up postgresql-client-common (111) ...
Setting up postgresql-client-9.0 (9.0.0-3) ...
update-alternatives: using /usr/share/postgresql/9.0/man/man1/psql.1.gz to 
provide /usr/share/man/man1/psql.1.gz (psql.1.gz) in auto mode.
Setting up postgresql-common (111) ...
Starting PostgreSQL 8.4 database server: main.
Setting up postgresql-9.0 (9.0.0-3) ...
Creating new cluster (configuration: /etc/postgresql/9.0/main, data: 
/var/lib/postgresql/9.0/main)...
Moving configuration file /var/lib/postgresql/9.0/main/postgresql.conf to 
/etc/postgresql/9.0/main...
Moving configuration file /var/lib/postgresql/9.0/main/pg_hba.conf to 
/etc/postgresql/9.0/main...
Moving configuration file /var/lib/postgresql/9.0/main/pg_ident.conf to 
/etc/postgresql/9.0/main...
Configuring postgresql.conf to use port 5433...
update-alternatives: using 
/usr/share/postgresql/9.0/man/man1/postmaster.1.gz to provide 
/usr/share/man/man1/postmaster.1.gz (postmaster.1.gz) in auto mode.
Starting PostgreSQL 9.0 database server: main.
Setting up postgresql (9.0.0-3) ...
Setting up postgresql-client (9.0.0-3) ...
Setting up postgresql-contrib-9.0 (9.0.0-3) ...
Setting up postgresql-contrib (9.0.0-3) ...
Setting up postgresql-plperl-9.0 (9.0.0-3) ...
Setting up postgresql-plpython-9.0 (9.0.0-3) ...
Press return to continue.

$ pg_lsclusters
Version Cluster   Port Status OwnerData directory 
Log file
8.4 main  5432 online postgres /var/lib/postgresql/8.4/main   
/var/log/postgresql/postgresql-8.4-main.log
9.0 main  5433 online postgres /var/lib/postgresql/9.0/main   
/var/log/postgresql/postgresql-9.0-main.log

So there's nothing *fundamentally* broken.  There may still be a bug that
causes the creation of the 9.0 cluster to fail under *specific* circum-
stances, of course.

BTW, Martin, thanks for your great work on the PostgreSQL packages!
I appreciate it very much.

-Julian


signature.asc
Description: This is a digitally signed message part.


Bug#598447: postgresql-9.0: provide a usable way of upgrade from previous 8.4 server

2010-09-28 Thread SkyRaT
Package: postgresql-9.0
Version: 9.0.0-3
Severity: important


Hi.

While having a previous 8.4 version of server installed and running, it
is impossible to install the package at all (automatic way).

Both services use the same 5432 TCP/IP port and so the second one fails
to start. DPKG fails to install the package because it depends on a
successfull startup of the service.

Here comes the manual way: change the port of already running 8.4 to e.g
5433, restart the service. Now install the 9.0. Auto started on 5432
port, both servers are running, using different ports, one can easily
migrate data and get rid of the old server.

I do not remember such behavior while upgrading 8.3 - 8.4. There was
something like auto-switch-to-next-port-available feature.

Thanks in advance. Cheers.

  Rene




-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages postgresql-9.0 depends on:
ii  libc6   2.11.2-6 Embedded GNU C Library: Shared lib
ii  libcomerr2  1.41.12-2common error description library
ii  libgssapi-krb5-21.8.3+dfsg-1 MIT Kerberos runtime libraries - k
ii  libkrb5-3   1.8.3+dfsg-1 MIT Kerberos runtime libraries
ii  libldap-2.4-2   2.4.23-6 OpenLDAP libraries
ii  libpam0g1.1.1-6  Pluggable Authentication Modules l
ii  libpq5  9.0.0-3  PostgreSQL C client library
ii  libssl0.9.8 0.9.8o-2 SSL shared libraries
ii  libxml2 2.7.7.dfsg-4 GNOME XML library
ii  locales 2.11.2-6 Embedded GNU C Library: National L
ii  postgresql-client-9.0   9.0.0-3  front-end programs for PostgreSQL 
ii  postgresql-common   111  PostgreSQL database-cluster manage
ii  ssl-cert1.0.26   simple debconf wrapper for OpenSSL
ii  tzdata  2010l-1  time zone and daylight-saving time

postgresql-9.0 recommends no packages.

Versions of packages postgresql-9.0 suggests:
ii  pidentd [ident-server]  3.0.19.ds1-5 TCP/IP IDENT protocol server with 

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org