Photo Organizer

That error is indeed bizzare..

What postgresql version are you running?

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

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.

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)

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.

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

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)

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

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.

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.

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.

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.