Photo Organizer

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bug Report
  • Category Installer
  • Assigned To No-one
  • Operating System Linux
  • Severity High
  • Priority Very Low
  • Reported Version 2.34
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Photo Organizer
Opened by Jürgen Kleff - 2007-11-26
Last edited by Solomon Peachy - 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...

Closed by  Solomon Peachy
2007-11-27 17:30
Reason for closing:  Fixed
Additional comments about closing:  svn r1781, both -devel and -stable.
Admin
Solomon Peachy commented on 2007-11-26 18:03

That error is indeed bizzare..

What postgresql version are you running?

Jürgen Kleff commented on 2007-11-26 18:11

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...!?

Admin
Solomon Peachy commented on 2007-11-27 16:22

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 commented on 2007-11-27 16:32

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 commented on 2007-11-27 16:38

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.

Admin
Solomon Peachy commented on 2007-11-27 16:39

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 commented on 2007-11-27 16:44

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 commented on 2007-11-27 16:51

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 ;-))

Admin
Solomon Peachy commented on 2007-11-27 16:59

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.

Admin
Solomon Peachy commented on 2007-11-27 17:07

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 commented on 2007-11-27 17:19

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.

Admin
Solomon Peachy commented on 2007-11-27 17:24

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...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing