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

[Yannick Warnier]

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