Assigning to maintainer

CC: (none) => stormi
Assignee: bugsquad => nanardon

Postgresql 8.4.9 and 9.0.5 are now submited to update/testing.

Assignee: nanardon => qa-bugs

Do postgresql and mysql conflict or is it safe to have both installed?

You can have both installed at the same time. The two postgresql versions do conflict (I think).

Tested i586 using drupal/pgadmin with 9.0.5. I don't think drupal works with the older version as it cannot be selected.

Any ideas how to test 8.4.9?

Postgesql8.4-server doesn't create a script in /etc/init.d to start it with.

Removing postgresql9.0-server left behind a user postgres with incorrect home dir for postgresql8.4-server, which required manual removal.

Oops yes it does.

Rpmdrake did not display any failure messages but did display an empty upgrade information. postgresql8.4-server was not installed.

# urpmi postgresql8.4-server-8.4.9-1.mga1
Marking postgresql8.4-server as manually installed, it won't be auto-orphaned
writing /var/lib/rpm/installed-through-deps.list


    $MIRRORLIST: media/core/updates_testing/postgresql8.4-server-8.4.9-1.mga1.i586.rpm
installing postgresql8.4-server-8.4.9-1.mga1.i586.rpm from /var/cache/urpmi/rpms
Preparing...                     #############################################

You currently have database tree for Postgresql 9.0
You must use postgresql9.0-server
To update you Postgresql server, dump your databases
delete /var/lib/pgsql/data/ content, upgrade the server, then
restore your databases from your backup

error: %pre(postgresql8.4-server-8.4.9-1.mga1.i586) scriptlet failed, exit status 1
error:   install: %pre scriptlet failed (2), skipping postgresql8.4-server-8.4.9-1.mga1
----------------------------------------------------------------------
More information on package postgresql8.4-server-8.4.9-1.mga1.i586

----------------------------------------------------------------------

I had to rm -rf /var/lib/pgsql/data and then it installed the server and init script.

Still not sure how to go about testing this beyond creating a database with pgadmin?

After a bit of research, testing with pgbench from the postgresql8.4-contrib package.

# su - postgres

$ pgbench -i
NOTICE:  table "pgbench_branches" does not exist, skipping
NOTICE:  table "pgbench_tellers" does not exist, skipping
NOTICE:  table "pgbench_accounts" does not exist, skipping
NOTICE:  table "pgbench_history" does not exist, skipping
creating tables...
10000 tuples done.
20000 tuples done.
30000 tuples done.
40000 tuples done.
50000 tuples done.
60000 tuples done.
70000 tuples done.
80000 tuples done.
90000 tuples done.
100000 tuples done.
set primary key...
NOTICE:  ALTER TABLE / ADD PRIMARY KEY will create implicit index "pgbench_branches_pkey" for table "pgbench_branches"
NOTICE:  ALTER TABLE / ADD PRIMARY KEY will create implicit index "pgbench_tellers_pkey" for table "pgbench_tellers"
NOTICE:  ALTER TABLE / ADD PRIMARY KEY will create implicit index "pgbench_accounts_pkey" for table "pgbench_accounts"
vacuum...done.

$ pgbench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
query mode: simple
number of clients: 1
number of transactions per client: 10
number of transactions actually processed: 10/10
tps = 67.922324 (including connections establishing)
tps = 70.359113 (excluding connections establishing)

So I think testing can be called completed i586 for postgresql 9.0.5 and 8.4.9.

It should probably be noted that uninstalling either postgresql version left behind the postgres user, which is not ideal.

x86_64:

9.0.5
-----

# pgbench -i -U postgres
creating tables...
10000 tuples done.
20000 tuples done.
30000 tuples done.
40000 tuples done.
50000 tuples done.
60000 tuples done.
70000 tuples done.
80000 tuples done.
90000 tuples done.
100000 tuples done.
set primary key...
NOTICE:  ALTER TABLE / ADD PRIMARY KEY will create implicit index "pgbench_branches_pkey" for table "pgbench_branches"
NOTICE:  ALTER TABLE / ADD PRIMARY KEY will create implicit index "pgbench_tellers_pkey" for table "pgbench_tellers"
NOTICE:  ALTER TABLE / ADD PRIMARY KEY will create implicit index "pgbench_accounts_pkey" for table "pgbench_accounts"
vacuum...done.

# pgbench -U postgres
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
query mode: simple
number of clients: 1
number of threads: 1
number of transactions per client: 10
number of transactions actually processed: 10/10
tps = 637.877145 (including connections establishing)
tps = 765.462339 (excluding connections establishing)

8.4.9
-----

# pgbench -i -U postgres
NOTICE:  table "pgbench_branches" does not exist, skipping
NOTICE:  table "pgbench_tellers" does not exist, skipping
NOTICE:  table "pgbench_accounts" does not exist, skipping
NOTICE:  table "pgbench_history" does not exist, skipping
creating tables...
10000 tuples done.
20000 tuples done.
30000 tuples done.
40000 tuples done.
50000 tuples done.
60000 tuples done.
70000 tuples done.
80000 tuples done.
90000 tuples done.
100000 tuples done.
set primary key...
NOTICE:  ALTER TABLE / ADD PRIMARY KEY will create implicit index "pgbench_branches_pkey" for table "pgbench_branches"
NOTICE:  ALTER TABLE / ADD PRIMARY KEY will create implicit index "pgbench_tellers_pkey" for table "pgbench_tellers"
NOTICE:  ALTER TABLE / ADD PRIMARY KEY will create implicit index "pgbench_accounts_pkey" for table "pgbench_accounts"
vacuum...done.

# pgbench -U postgres
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
query mode: simple
number of clients: 1
number of threads: 1
number of transactions per client: 10
number of transactions actually processed: 10/10
tps = 635.324015 (including connections establishing)
tps = 754.546140 (excluding connections establishing)

Testing complete x86_64.

Before I validate, do you wish to provide a fix to remove the postgres user left behind with a bash login when uninstalling?

Awaiting packager input.

Assignee: qa-bugs => nanardon

The removal of user on rpm uninstall has never been done. This is true for all services.

Validating in that case :)

Advisory:
-------------
This release fixes a long list of bugs, including several potential crash and data-corruption issues, including:

    Applied upstream fix in contrib/pg_crypto for blowfish signed-character bug (CVE-2011-2483), where encryption code could give wrong results on platforms where char is signed (which is most), leading to encrypted passwords being weaker than they should be;

    Work-around for gcc 4.6.0 bug that breaks WAL replay;

    Fixed memory leak at end of a GiST index scan;

    Improved handling of SSL errors;

    Fixed SSPI login when multiple roundtrips are required (typical error reported was "The function requested is not supported");

    Fixed VACUUM so that it always updates pg_class.reltuples and pg_class.relpages;

    Allowed the planner to assume that empty parent tables really are empty;

    Disallowed SELECT FOR UPDATE/SHARE on sequences;

    Fixed failure when DROP OWNED BY attempts to remove default privileges on sequences. 

Please see http://www.postgresql.org/about/news.1355 for full details.

-------------------------------

SRPMs:

postgresql8.4-8.4.9-1.mga1.src.rpm
postgresql9.0-9.0.5-1.mga1.src.rpm


Could sysadmin please push from core/updates_testing to core/updates

Thankyou!

Keywords: (none) => validated_update
CC: qa-bugs => sysadmin-bugs
Hardware: i586 => All
Assignee: nanardon => qa-bugs

update pushed.

Status: NEW => RESOLVED
CC: (none) => dmorganec
Resolution: (none) => FIXED