[development] Upgrades from 5.7 to 6.2 with PostgreSQL - how to debug?

[Matthew Farina]

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