Upgrade from 2.5.0 to 2.5.2 does not work [message #12295] |
Sun, 03 August 2003 01:31 |
|
When I access the upgrade.php file, it first refused to work because it tried to access the database MySQL, but I'm using a PostgreSQL database. So I put in the beginning of the upgrade.php file the following: define('__dbtype__', 'pgsql');
Next, when accessing the upgrade.php file, it asks me for the admin password. When I supply it, it begins (seems to) to upgrade, but stops at: Begining to decompress the archive.
There is no other message, no error message, nothing. The navigator is 'loading' the page, but never stops (I guess there will be a timeout after a long time
I saw a similar message on the forum explaining it was a memory_limit problem. I had it set to 8M, I put 4000M, and even commented the line, nothing changes.
In the database logs, I see the following, nothing else:
[5] LOG: query: DROP TABLE fud_forum_upgrade_test_table
[6] ERROR: table "fud_forum_upgrade_test_table" does not exist
[7] LOG: statement: DROP TABLE fud_forum_upgrade_test_table
[8] LOG: query: CREATE TABLE fud_forum_upgrade_test_table (test_val INT)
[9] LOG: query: ALTER TABLE fud_forum_upgrade_test_table ADD test_val2 INT
[10] LOG: query: DROP TABLE fud_forum_upgrade_test_table
Any idea?
[Updated on: Sun, 03 August 2003 01:35] Report message to a moderator
|
|
|
Re: Upgrade from 2.5.0 to 2.5.2 does not work [message #12297 is a reply to message #12295] |
Sun, 03 August 2003 01:42 |
Ilia
Messages: 13241 Registered: January 2002
Karma: 0
|
Senior Member Administrator Core Developer |
|
|
As of 2.5.1 memory limit is a non issue so raising the memory limit won't help.
Let's start from the top, on line 1001 of the upgrade script there is a line that tries to determine what database type your forum is using. Something goes wrong on that line and causes incorrect database type detection.
Above this line try adding the following code and see if it could give you any clues as to why database was not determined correctly.
<?php $a = $GLOBALS['DATA_DIR'] . 'include/theme/default/db.inc'; $b = $GLOBALS['DATA_DIR'] . 'sql/pgsql/db.inc';
echo "Compiled {$a} ".md5_file($a)."\n"; echo "Source {$b} ".md5_file($b)."\n"; ?>
Now for arvhive decomoression. At the top of the file find function called
upgrade_decompress_archive().
Inside that function find a line which has fopen() and right above it add
<?php echo $path . " "; ?>
If it dies decompressing files at least we'll know on which file it died.
FUDforum Core Developer
|
|
|
Re: Upgrade from 2.5.0 to 2.5.2 does not work [message #12298 is a reply to message #12295] |
Sun, 03 August 2003 01:43 |
Ilia
Messages: 13241 Registered: January 2002
Karma: 0
|
Senior Member Administrator Core Developer |
|
|
The queries you've shown are used to detect permission necessary for the upgrade. It means that the upgrade script did not reach the SQL upgrading stage and died somewhere during the file decompression.
FUDforum Core Developer
|
|
|
Re: Upgrade from 2.5.0 to 2.5.2 does not work [message #12300 is a reply to message #12297] |
Sun, 03 August 2003 02:24 |
|
Using your changes, it writes:
Compiled /var/www/FUDforum/include/theme/default/db.inc edf710572b912198f0b12d2c40e0d181
Source /var/www/FUDforum/sql/pgsql/db.inc 59ae7fed212306023c6f3a8a8086353b LLLDisable the forum
So I guess it should detect that I use PostgreSQL? But it continues to try to use MySQL.
So if I force the use of PostgreSQL, and try your second modification, to see on which file it has a problem, it passes all the files, so it's not a problem in this function.
I put echos to isolate the position where it blocks, and finished on the htaccess_handler() function. it blocks in this function, on the @fopen() call.
If I comment the call to htaccess_handler(), it continues !
I get a warning:
Warning: pg_query() query failed: ERROR: Cannot insert a duplicate key into unique index pg_class_relname_nsp_index in /var/www/dvartorah/upgrade.php on line 193
and the an error:
PostgreSQL Error: ERROR: Cannot insert a duplicate key into unique index pg_class_relname_nsp_index
Query: UPDATE pg_class SET relname='fud25_fn_idx_fid' WHERE relname='fud25_forum_notify_index_forum_id' AND relkind='i'
And then stops there. I guess the install is not finished
(btw, I'm using PostgresSQL v7.3.2)
[Updated on: Sun, 03 August 2003 02:28] Report message to a moderator
|
|
|
Re: Upgrade from 2.5.0 to 2.5.2 does not work [message #12302 is a reply to message #12300] |
Sun, 03 August 2003 16:22 |
Ilia
Messages: 13241 Registered: January 2002
Karma: 0
|
Senior Member Administrator Core Developer |
|
|
Thanks for the detailed info, the blocking on htaccess_handle can be explained by your server either running with only 1 apache child or declining requests from itself. I'll look into adding a short timeout to ensure that this check cannot stall the upgrade script.
The actual error is more interesting. What it tries to do it replace overly long index names used in prior releases with shorter alternatives. Unfortunately, it appears to bomb on your system which technically should not be possible since it implies that both the old & the new index exists at the same time. I'll take a look @ what may have caused this.
Meanwhile could you please confirm that both fud25_fn_idx_fid & 'fud25_forum_notify_index_forum_id exist inside the pg_class table?
FUDforum Core Developer
|
|
|
|
Re: Upgrade from 2.5.0 to 2.5.2 does not work [message #12304 is a reply to message #12302] |
Sun, 03 August 2003 17:21 |
|
prottoss wrote on Sun, 03 August 2003 18:22 | Meanwhile could you please confirm that both fud25_fn_idx_fid & 'fud25_forum_notify_index_forum_id exist inside the pg_class table?
|
Yes, I confirm, both of them are present, I don't know why, maybe because of the failed upgrade? I may have upgraded half of the base?
fudbase=# \d fud25_forum_notify_index_forum_id
Index "public.fud25_forum_notify_index_forum_id"
Column | Type
----------+---------
forum_id | integer
btree, for table "public.fud25_forum_notify"
fudbase=# \d fud25_fn_idx_fid
Index "public.fud25_fn_idx_fid"
Column | Type
----------+---------
forum_id | integer
btree, for table "public.fud25_forum_notify"
About the version of PHP, I use PHP v4.2.3, from a normal debian package.
I'd don't really know in what state is my db/site, I still access it correctly, it says v2.5.2, posts work, but when I try to use/modify the themes, everything explodes, I get a blank screen.
If I put back my backuped (always make backups index.php, it displays back my pages. So to summarize, it seems I can't do theme stuff (because of the change in its db structure I guess).
Thanks,
Luc
|
|
|
Re: Upgrade from 2.5.0 to 2.5.2 does not work [message #12305 is a reply to message #12304] |
Sun, 03 August 2003 17:32 |
Ilia
Messages: 13241 Registered: January 2002
Karma: 0
|
Senior Member Administrator Core Developer |
|
|
I believe I have made a fix for the query failure bug and am working on a htacccess problem. Since 4.2.3 does not have a mechanism to set a timeout value like 4.3+ versions do I am going to use fsockeopen which does to write an alternative. The 'real' puzzling bit for me is the cause of the inccorect database type detection...
FUDforum Core Developer
|
|
|
Re: Upgrade from 2.5.0 to 2.5.2 does not work [message #12312 is a reply to message #12305] |
Mon, 04 August 2003 07:44 |
|
prottoss wrote on Sun, 03 August 2003 19:32 | I believe I have made a fix for the query failure bug and am working on a htacccess problem. Since 4.2.3 does not have a mechanism to set a timeout value like 4.3+ versions do I am going to use fsockeopen which does to write an alternative. The 'real' puzzling bit for me is the cause of the inccorect database type detection...
|
Ok, I tried the upgrade.php from CVS (2003-08-04 09:50). The upgrade script doesn't block anymore on the htaccess, but it still doesn't recognize the database type (postgresql). I'll try to trace where does it loose that '__dbtype__'.
For now I'm putting define('__dbtype__', 'pgsql'); at the beginning of the file.
On the SQL upgrade, it chokes/stops on a new error:
PostgreSQL Error: ERROR: ALTER TABLE: Attribute "pm_notify" contains NULL values
Query: ALTER TABLE fud25_users ALTER COLUMN pm_notify SET NOT NULL
What's supposed to be in this pm_notify? I just see it's a sequence.
[Updated on: Mon, 04 August 2003 07:49] Report message to a moderator
|
|
|
Re: Upgrade from 2.5.0 to 2.5.2 does not work [message #12313 is a reply to message #12312] |
Mon, 04 August 2003 07:58 |
|
Arg, If I rerun the upgrade.php script, it seems that if the upgrade failed in the SQL part, you're dead. Especially if you haven't made a backup before :-)
I noticed that it skips the ALTER error now (previously posted) and prints another error, so I guess that it didn't do the change, but in some way jumped on the next problem?
There should be a rollback, in case of any error, no? I don't know if it's possible with MySQL, but with PostgreSQL it's definitely possible.
I now have the following error:
PostgreSQL Error: ERROR: Relation 818500 does not exist
Query: UPDATE fud25_group_members SET user_id=2147483647 WHERE user_id=4294967295
I get the error "Relation 818500 does not exist" on any request that I make now. Even when doinga consistency check :-(
Does this mean that my db is totally corrupted?
[Updated on: Mon, 04 August 2003 08:00] Report message to a moderator
|
|
|
|
Re: Upgrade from 2.5.0 to 2.5.2 does not work [message #12316 is a reply to message #12312] |
Mon, 04 August 2003 16:11 |
Ilia
Messages: 13241 Registered: January 2002
Karma: 0
|
Senior Member Administrator Core Developer |
|
|
First of all see if the PostgreSQL can fetch the structure of the fud25_group_members table from the command line. See if this will give you any errors
FUDforum Core Developer
|
|
|
Re: Upgrade from 2.5.0 to 2.5.2 does not work [message #12317 is a reply to message #12312] |
Mon, 04 August 2003 16:13 |
Ilia
Messages: 13241 Registered: January 2002
Karma: 0
|
Senior Member Administrator Core Developer |
|
|
lstep wrote on Mon, 04 August 2003 03:44 |
On the SQL upgrade, it chokes/stops on a new error:
PostgreSQL Error: ERROR: ALTER TABLE: Attribute "pm_notify" contains NULL values
Query: ALTER TABLE fud25_users ALTER COLUMN pm_notify SET NOT NULL
What's supposed to be in this pm_notify? I just see it's a sequence.
|
Hmm strange error this is the last item in SQL upgrading and it shouldn't have failed since the table has a default value for that column that should've been set upon the column addition.
FUDforum Core Developer
|
|
|
Re: Upgrade from 2.5.0 to 2.5.2 does not work [message #12321 is a reply to message #12316] |
Mon, 04 August 2003 17:16 |
|
prottoss wrote on Mon, 04 August 2003 18:11 | First of all see if the PostgreSQL can fetch the structure of the fud25_group_members table from the command line. See if this will give you any errors
|
Doing a \d fud25_group_members from psql shows me the structure of the table, but doing a 'select * from fud25_group_members gives an error:
fudbase=# select * from fud25_group_members;
ERROR: Relation 818500 does not exist
How is this possible? Is there a trigger somewhere?
[Updated on: Mon, 04 August 2003 17:16] Report message to a moderator
|
|
|
|
Re: Upgrade from 2.5.0 to 2.5.2 does not work [message #12323 is a reply to message #12317] |
Mon, 04 August 2003 17:20 |
|
prottoss wrote on Mon, 04 August 2003 18:13 |
lstep wrote on Mon, 04 August 2003 03:44 |
On the SQL upgrade, it chokes/stops on a new error:
PostgreSQL Error: ERROR: ALTER TABLE: Attribute "pm_notify" contains NULL values
Query: ALTER TABLE fud25_users ALTER COLUMN pm_notify SET NOT NULL
What's supposed to be in this pm_notify? I just see it's a sequence.
|
Hmm strange error this is the last item in SQL upgrading and it shouldn't have failed since the table has a default value for that column that should've been set upon the column addition.
|
You're right, it's very strange. The record is set up to reveice a value from a sequence, so it should be ok:
fudbase=# select pm_notify from fud25_users limit 1;
pm_notify
-----------
(1 row)
May I do a update fud25_users set pm_notify = 1; ? What's the use of that pm_notify? (I've got 2 users, that not really a problem I guess)
|
|
|
Re: Upgrade from 2.5.0 to 2.5.2 does not work [message #12324 is a reply to message #12323] |
Mon, 04 August 2003 17:23 |
Ilia
Messages: 13241 Registered: January 2002
Karma: 0
|
Senior Member Administrator Core Developer |
|
|
pm_notify field has a constraint allowing only 'Y' or 'N' values, you can try inserting either value, but it should've already been populated during column creation.
FUDforum Core Developer
|
|
|
Re: Upgrade from 2.5.0 to 2.5.2 does not work [message #12325 is a reply to message #12322] |
Mon, 04 August 2003 17:42 |
|
prottoss wrote on Mon, 04 August 2003 19:18 | Try running the following query:
DROP INDEX group_members_index_group_id_user_id;
|
Hmm, I dont' have this index in my database all of the tables and indexes are all beginning with 'fud25_'. For example:
public | fud25_group_cache_pkey | index | fuduser | fud25_group_cache
public | fud25_group_members_pkey | index | fuduser | fud25_group_members
public | fud25_group_resources_pkey | index | fuduser | fud25_group_resources
And no index look like the one you ask me to drop (even without the 'fud_25').
|
|
|
Re: Upgrade from 2.5.0 to 2.5.2 does not work [message #12326 is a reply to message #12324] |
Mon, 04 August 2003 17:45 |
|
prottoss wrote on Mon, 04 August 2003 19:23 | pm_notify field has a constraint allowing only 'Y' or 'N' values, you can try inserting either value, but it should've already been populated during column creation.
|
hmmm???? In my database, the type of pm_notify is not a char or varchar, it is a sequence, which is automatically incremented when asked to. You can't put an char into this:
pm_notify | integer | default nextval('fud25_users_pm_notify_seq'::text)
I swear I haven't played with the data types of any record!
|
|
|
|
Re: Upgrade from 2.5.0 to 2.5.2 does not work [message #12328 is a reply to message #12326] |
Mon, 04 August 2003 18:15 |
Ilia
Messages: 13241 Registered: January 2002
Karma: 0
|
Senior Member Administrator Core Developer |
|
|
lstep wrote on Mon, 04 August 2003 13:45 |
hmmm???? In my database, the type of pm_notify is not a char or varchar, it is a sequence, which is automatically incremented when asked to. You can't put an char into this:
pm_notify | integer | default nextval('fud25_users_pm_notify_seq'::text)
I swear I haven't played with the data types of any record!
|
I found the problem with pm_notify and fixed in latest CVS. Here is what you need to do:
ALTER TABLE fud25_users DROP COLUMN pm_notify;
then get a fresh upgrade script from the CVS and run it.
FUDforum Core Developer
|
|
|
Re: Upgrade from 2.5.0 to 2.5.2 does not work [message #12329 is a reply to message #12327] |
Mon, 04 August 2003 20:40 |
|
prottoss wrote on Mon, 04 August 2003 19:46 | err sorry
DROP INDEX fud25_group_members_index_group_id_user_id;
|
Hmm, I don't have this either, here are the one that begin with fud25_group*. Is this one of them?
public | fud25_gci_group_id | index | fuduser | fud25_group_cache
public | fud25_gm_idx_gid_uid | index | fuduser | fud25_group_members
public | fud25_gm_idx_gl | index | fuduser | fud25_group_members
public | fud25_gr_idx_gid_rid | index | fuduser | fud25_group_resources
public | fud25_gr_idx_rid | index | fuduser | fud25_group_resources
public | fud25_group_cache_pkey | index | fuduser | fud25_group_cache
public | fud25_group_members_pkey | index | fuduser | fud25_group_members
public | fud25_group_resources_pkey | index | fuduser | fud25_group_resources
public | fud25_groups_forum_id | index | fuduser | fud25_groups
public | fud25_groups_inherit_id | index | fuduser | fud25_groups
public | fud25_groups_pkey | index | fuduser | fud25_groups
|
|
|
Re: Upgrade from 2.5.0 to 2.5.2 does not work [message #12330 is a reply to message #12329] |
Mon, 04 August 2003 20:43 |
Ilia
Messages: 13241 Registered: January 2002
Karma: 0
|
Senior Member Administrator Core Developer |
|
|
Hmm.. allright try the new upgrade script after removing the column pm_notify. It first of all should correctly detect your database type and should complete the SQL upgrades without errors.
FUDforum Core Developer
|
|
|
Re: Upgrade from 2.5.0 to 2.5.2 does not work [message #12339 is a reply to message #12330] |
Tue, 05 August 2003 09:16 |
|
prottoss wrote on Mon, 04 August 2003 22:43 | Hmm.. allright try the new upgrade script after removing the column pm_notify. It first of all should correctly detect your database type and should complete the SQL upgrades without errors.
|
I still had that 'relation 8343224 does not exist'. I pg_dump'ed my base, and reimported my base with another name and changed in the GLOBALS.inc the name of my base, that error disappeared.
(maybe you should make a FAQ about this
Yes! It detected correctly the database type. It still blocked on the htaccess() function, even thought there is that timeout you added. It doesn't seem to be that efficient. When I put echos, it locks *exactly* on that "@fopen(www_root..." function.
The content of the www_root variable is the url of my website ("http://www.foobar.com")
Well, I commented the call and everything went fine (well it went up to the end of the upgrade, the consistency check and the sql optimization).
The rebuild of the theme are working (at least for now) even the path_info theme.
Thanks
|
|
|
|
Re: Upgrade from 2.5.0 to 2.5.2 does not work [message #12341 is a reply to message #12340] |
Tue, 05 August 2003 11:16 |
|
prottoss wrote on Tue, 05 August 2003 11:27 | The htaccess check still requires modifications to work properly on <4.3.0 systems, that'll add.
I take it the forum is working correctly now?
|
Yes it is working correctly, thanks for your help, you are really great!
|
|
|
|