Upgrades from 5.7 to 6.2 with PostgreSQL - how to debug?
Hello, I've been ripping my hair off my head for the last few hours trying to find out why the hell my Drupal 5.2 site wouldn't let me upgrade it to 6.2. I'm using PostgreSQL 7.4 and I'm apparently running into more problems because of that, but it doesn't seem to be the blocking point. I think I've done everything I should have done. I have followed the upgrade procedure to the letter (from UPGRADE.txt in 6.2). I have a 5.2 to start with, but a direct upgrade to 6.2 failed - database errors in adding columns with default values - apparently PG 7.4 doesn't allow that, but there seems to be some code to tackle that in includes/database.psql.inc but I'm afraid I'll have to report a problem in that code, as it doesn't divide an ADD COLUMN query with default values into a ADD COLUMN and an ALTER COLUMN as it should. So I decided to do these field updates manually (cache.serialized and this kind of stuff, about 16 queries) and that did help, but I got stuck in the modules update process. Looking into it, it seemed that the process got stuck right after processing system_update_6019() which is in the /modules/system/system.install file. So I first tried to divide this into little steps. I upgraded from 5.2 to 5.7 and that went all right. No problem at all, smooth upgrade. Then I tried again from 5.7 to 6.2. Again, it failed right after 6019. So I started to debug (a lot) and after long hours trying to understand how the process jumped from one update to the other, I must say I still don't get it, and I think that's why I haven't been able to fix the problem until now. Meanwhile, I realised that, inside 6019, there were a few queries that didn't make it with PostgreSQL 7.4. Notably, the field type change for boxes.bid (to serial) which did apparently not pass correctly through the database queries parsing functions. Anyway, so fed up of trying this, I tried an upgrade from 5.7 to 6.0, but I get stuck on the same problem there (around 6019). Surprisingly, changing the refresh time at the end of the while (!$current_set['success']) { loop inside _batch.inc :: _batch_process() seemed to change the position where the upgrade process halts. However, it only varies from 6016 to 6021, no matter what the time change is. Most than anything else, I've been looking at how to identify what exactly is breaking the upgrade process, but without a developer's insight on this, I fear I might be loosing a lot more hours trying to figure it out. I've looked into the batch table, but it doesn't really speak to me... So, could someone give me a hand? Yannick
@Yannick - Is there an open issue for this? On Apr 17, 2008, at 11:18 PM, Yannick Warnier wrote:
Hello,
I've been ripping my hair off my head for the last few hours trying to find out why the hell my Drupal 5.2 site wouldn't let me upgrade it to 6.2. I'm using PostgreSQL 7.4 and I'm apparently running into more problems because of that, but it doesn't seem to be the blocking point.
I think I've done everything I should have done. I have followed the upgrade procedure to the letter (from UPGRADE.txt in 6.2).
I have a 5.2 to start with, but a direct upgrade to 6.2 failed - database errors in adding columns with default values - apparently PG 7.4 doesn't allow that, but there seems to be some code to tackle that in includes/database.psql.inc but I'm afraid I'll have to report a problem in that code, as it doesn't divide an ADD COLUMN query with default values into a ADD COLUMN and an ALTER COLUMN as it should.
So I decided to do these field updates manually (cache.serialized and this kind of stuff, about 16 queries) and that did help, but I got stuck in the modules update process. Looking into it, it seemed that the process got stuck right after processing system_update_6019() which is in the /modules/system/system.install file.
So I first tried to divide this into little steps. I upgraded from 5.2 to 5.7 and that went all right. No problem at all, smooth upgrade.
Then I tried again from 5.7 to 6.2. Again, it failed right after 6019. So I started to debug (a lot) and after long hours trying to understand how the process jumped from one update to the other, I must say I still don't get it, and I think that's why I haven't been able to fix the problem until now.
Meanwhile, I realised that, inside 6019, there were a few queries that didn't make it with PostgreSQL 7.4. Notably, the field type change for boxes.bid (to serial) which did apparently not pass correctly through the database queries parsing functions.
Anyway, so fed up of trying this, I tried an upgrade from 5.7 to 6.0, but I get stuck on the same problem there (around 6019).
Surprisingly, changing the refresh time at the end of the
while (!$current_set['success']) {
loop inside _batch.inc :: _batch_process() seemed to change the position where the upgrade process halts. However, it only varies from 6016 to 6021, no matter what the time change is.
Most than anything else, I've been looking at how to identify what exactly is breaking the upgrade process, but without a developer's insight on this, I fear I might be loosing a lot more hours trying to figure it out. I've looked into the batch table, but it doesn't really speak to me...
So, could someone give me a hand?
Yannick
Le vendredi 18 avril 2008 à 05:45 -0400, Matthew Farina a écrit :
@Yannick - Is there an open issue for this?
Hi Matthew, Not that I know of. Where should I look for it? I've googled it a lot but nothing came up that was related to it. -- Yannick
On Apr 17, 2008, at 11:18 PM, Yannick Warnier wrote:
Hello,
I've been ripping my hair off my head for the last few hours trying to find out why the hell my Drupal 5.2 site wouldn't let me upgrade it to 6.2. I'm using PostgreSQL 7.4 and I'm apparently running into more problems because of that, but it doesn't seem to be the blocking point.
I think I've done everything I should have done. I have followed the upgrade procedure to the letter (from UPGRADE.txt in 6.2).
I have a 5.2 to start with, but a direct upgrade to 6.2 failed - database errors in adding columns with default values - apparently PG 7.4 doesn't allow that, but there seems to be some code to tackle that in includes/database.psql.inc but I'm afraid I'll have to report a problem in that code, as it doesn't divide an ADD COLUMN query with default values into a ADD COLUMN and an ALTER COLUMN as it should.
So I decided to do these field updates manually (cache.serialized and this kind of stuff, about 16 queries) and that did help, but I got stuck in the modules update process. Looking into it, it seemed that the process got stuck right after processing system_update_6019() which is in the /modules/system/system.install file.
So I first tried to divide this into little steps. I upgraded from 5.2 to 5.7 and that went all right. No problem at all, smooth upgrade.
Then I tried again from 5.7 to 6.2. Again, it failed right after 6019. So I started to debug (a lot) and after long hours trying to understand how the process jumped from one update to the other, I must say I still don't get it, and I think that's why I haven't been able to fix the problem until now.
Meanwhile, I realised that, inside 6019, there were a few queries that didn't make it with PostgreSQL 7.4. Notably, the field type change for boxes.bid (to serial) which did apparently not pass correctly through the database queries parsing functions.
Anyway, so fed up of trying this, I tried an upgrade from 5.7 to 6.0, but I get stuck on the same problem there (around 6019).
Surprisingly, changing the refresh time at the end of the
while (!$current_set['success']) {
loop inside _batch.inc :: _batch_process() seemed to change the position where the upgrade process halts. However, it only varies from 6016 to 6021, no matter what the time change is.
Most than anything else, I've been looking at how to identify what exactly is breaking the upgrade process, but without a developer's insight on this, I fear I might be loosing a lot more hours trying to figure it out. I've looked into the batch table, but it doesn't really speak to me...
So, could someone give me a hand?
Yannick
Hi Yannick, I'm the person responsible for PostgreSQL related bits in Drupal. Please post an issue for your problem and mail the URL to me. Cheers, -- Sammy Spets Synerger http://synerger.com
Le vendredi 18 avril 2008 à 05:45 -0400, Matthew Farina a écrit :
@Yannick - Is there an open issue for this?
Hi Matthew,
Not that I know of. Where should I look for it? I've googled it a lot but nothing came up that was related to it.
participants (3)
-
Matthew Farina -
Sammy Spets -
Yannick Warnier