Photo Organizer

Notice: Undefined index: tasklist_type in /var/www/flyspray/includes/class.tpl.php(128) : eval()'d code on line 85 Notice: Undefined index: tasklist_type in /var/www/flyspray/includes/class.tpl.php(128) : eval()'d code on line 90
  • Status Closed
  • Percent Complete
    100%
  • Task Type Bug Report
  • Category Installer
  • Assigned To No-one
  • Operating System Linux
  • Severity High
  • Priority Normal
  • Reported Version 2.34
  • Due in Version Undecided
  • Due Date Undecided
  • Votes 0
  • Private No
Attached to Project: Photo Organizer
Opened by Jürgen Kleff (juergen) - 2007-11-26
Last edited by Solomon Peachy (pizza) - 2007-11-27

FS#311 - fresh install hangs on sql/db error

Hi, I was doing a new install 2.34b from scratch on a OpenSuse 10.0. Following the install guide, then calling po/install.php. Result:

[...]
Upgrading from Photo Organizer version 2.33

* Upgrading database structure...OK
* Upgrading database data...

-- FAILED: update folder set date_changed = (select max(date_of_creation) from folder f2 where f2.parent_folder = folder.identifier) where date_changed is null


FAILED
*

FEHLER: could not open relation with OID 23434
CONTEXT: SQL-Anweisung »SELECT 1 FROM ONLY "public"."users" x WHERE "identifier" = $1 FOR UPDATE OF x«


No idea what that could be...

This task does not depend on any other tasks.

Closed by  Solomon Peachy (pizza)
Tuesday, 27 November 2007, 17:30 GMT
Reason for closing:  Fixed
Additional comments about closing:  svn r1781, both -devel and -stable.
Solomon Peachy (pizza)
Monday, 26 November 2007, 18:03 GMT
That error is indeed bizzare..

What postgresql version are you running?
Jürgen Kleff (juergen)
Monday, 26 November 2007, 18:11 GMT
postgresql version 8.0.13, as shipped with OpenSuse 10.0

ah, and I had to create the po_user with createuser -A, for this version had no '-S -R' flags...!?
Solomon Peachy (pizza)
Tuesday, 27 November 2007, 16:22 GMT
You're right, PG8.0's createuser needs the -A option. I just fixed the wiki.

First, I'm assuming you've tried to drop and recreate the datebase? It still errors out?

If you still have the broken database, what does this give you?

select * from pg_class where oid = 23434; -- or whatever the actual OID from the error was..

I don't have access to a PG8.0 box at the moment, but The po-devel demo site was running on PG8.0 for a while, so I'm not sure were this problem would have come from.
Jürgen Kleff (juergen)
Tuesday, 27 November 2007, 16:32 GMT
I first installed soem days ago version 2.34a, same error as when I installed with 2.34b. Yeah, dropped the tables and all.

po_db=# select * from pg_class where oid = 23434;
relname | relnamespace | reltype | relowner | relam | relfilenode | reltablespace | relpages | reltuples | reltoastrelid | reltoastidxid | relhasindex | relisshared | relkind | relnatts | relchecks | reltriggers | relukeys | relfkeys | relrefs | relhasoids | relhaspkey | relhasrules | relhassubclass | relacl
-----------+--------------+---------+----------+-------+-------------+---------------+----------+-----------+---------------+---------------+-------------+-------------+---------+----------+-----------+-------------+----------+----------+---------+------------+------------+-------------+----------------+--------
users_idx | 2200 | 0 | 100 | 403 | 23434 | 0 | 1 | 0 | 0 | 0 | f | f | i | 1 | 0 | 0 | 0 | 0 | 0 | f | f | f | f |
(1 Zeile)

Jürgen Kleff (juergen)
Tuesday, 27 November 2007, 16:38 GMT
ah, wait! second and folowing calls of install.php give:

Current Photo Organizer DB version: 2.33
Upgrading from Photo Organizer version 2.33

* Upgrading database structure...OK
* Upgrading database data...

-- FAILED: update album set date_changed = (select max(date_changed) from photo, album_content where album_content.album = album.identifier and album_content.photo = photo.identifier)


FAILED
*

FEHLER: could not open relation with OID 23434
CONTEXT: SQL-Anweisung »SELECT 1 FROM ONLY "public"."users" x WHERE "identifier" = $1 FOR UPDATE OF x«


so now it's update album, not update folders anymore where's the error...

ok, I'll do another fresh install... I'll be back.
Solomon Peachy (pizza)
Tuesday, 27 November 2007, 16:39 GMT
That's interesting; 'users_idx' is supposed to have been dropped in the "Upgrading database structure" phase.

I'm beginning to suspect the error message is misleading. the users table (and its indices) has no bearing on the query that's supposedly failing.

If you run the failed query directly:

update folder set date_changed = (select max(date_of_creation) from folder f2 where f2.parent_folder = folder.identifier) where date_changed is null;

What happends?

And for sanity's sake, what does this return:

\dt files

Jürgen Kleff (juergen)
Tuesday, 27 November 2007, 16:44 GMT
another fresh install, same error (with "update folder" now again), and:

po_db=# select * from pg_class where oid = 26659;
relname | relnamespace | reltype | relowner | relam | relfilenode | reltablespace | relpages | reltuples | reltoastrelid | reltoastidxid | relhasindex | relisshared | relkind | relnatts | relchecks | reltriggers | relukeys | relfkeys | relrefs | relhasoids | relhaspkey | relhasrules | relhassubclass | relacl
-----------+--------------+---------+----------+-------+-------------+---------------+----------+-----------+---------------+---------------+-------------+-------------+---------+----------+-----------+-------------+----------+----------+---------+------------+------------+-------------+----------------+--------
users_idx | 2200 | 0 | 100 | 403 | 26659 | 0 | 1 | 0 | 0 | 0 | f | f | i | 1 | 0 | 0 | 0 | 0 | 0 | f | f | f | f |
(1 Zeile)
Jürgen Kleff (juergen)
Tuesday, 27 November 2007, 16:51 GMT
running the query directly, with "update album" and "update folder" in both cases it says row "date_changed" doesnt exist.

\dt files says no matching relation found (something like that, my postgresql is speaking german ;-))
Solomon Peachy (pizza)
Tuesday, 27 November 2007, 16:59 GMT
Upon checking it appears that we're updating both the DB and DATA files in a single transaction. We perform a query against the users table after we've nuked the index; that would explain the error message -- but not the fact that an unrelated query is just failing.

If your re-test fails, try modifiying src/sql/po.db.2.33.to.2.34.sql, adding '-- ' before the 'drop index users_idx;' on line 376. Add 'drop index users_idx;' at the end of src/sql/po.data.2.33.to.2.34.sql -- this should silence that error.
Solomon Peachy (pizza)
Tuesday, 27 November 2007, 17:07 GMT
I've been putting it off for a while, but it would appear that for PO 2.35 it's finally time to rework the installer so that we always start with the latest schema for new installs, instead of going through the current 'start at the beginning, and upgrade each version in turn..) mess.
Jürgen Kleff (juergen)
Tuesday, 27 November 2007, 17:19 GMT
yeah those modifications on po.db and po.data helped :-) Thanks a lot!

I appreciated it a lot when I noticed that the installer would do even automatic upgrades for me (if I had a running po before). Just wondered why it had a problem witha fresh install :-)

Anyway, thank you for your great work and your help. Maybe if I go deeper into the code by the time, I could give soem help back.
Solomon Peachy (pizza)
Tuesday, 27 November 2007, 17:24 GMT
Well, I'm glad that change fixed things; I honestly wasn't expecting that.

I'll make those changes to the svn tree and a 2.34c release will probably follow shortly.

Loading...