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

[Yannick Warnier]

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