[rt-users] Upgrade History shows Upgrade Incomplete

Wed May 21 17:36:50 EDT 2014

After looking at all of the schema.Pg files after 4.1.1, it looks like all
of the changes have already been applied.  The subsequent changes in the
4.1.1 script have also been applied already (Disabled column was added,
Stage and Queue columns were removed), so I don't think it would work to
patch my 4.1.1 file and run the upgrade again.

>From what I can tell, the upgrade was successful the first time and failed
the second time, which is probably for the best anyway.  I'm not sure what
caused that, but I did notify Dominic about it.  I guess unless I notice
any problems, I'm just going to leave it and consider it to be normal/clean.

Thanks,
Nate

On Wed, May 21, 2014 at 4:23 PM, Nathan Baker <bakern at gmail.com> wrote:

>
> On Wed, May 21, 2014 at 1:22 PM, Kevin Falcone <falcone at bestpractical.com>wrote:
>
>> On Wed, May 21, 2014 at 11:33:20AM -0400, Nathan Baker wrote:
>> > Hello everyone,
>> >
>> > I just upgraded from 4.0.6 to 4.2.3 using the Debian packages.  During
>> the
>> > database upgrade, I received a few errors:
>>
>> I'm guessing you set up a new machine, installed request-tracker4 from
>> testing, restored your database and then did the upgrade?
>>
>
> Actually this is on a system that was running 4.0.6 previously.  I just
> did apt-get install request-tracker4 (using the testing repository) and it
> upgraded all the packages.
>
>
>> You have an unclean database with 4.2 tables in it, and you're
>> tripping over some of the code we added to help RT handle that more
>> gracefully.
>>
>
> What I'm wondering is how I can tell if the database is "unclean" or if
> it's okay.  The "upgrade history" section in System Configuration shows
> that it did "Upgrade from 4.0.19 to 4.2.3" once without errors, and then it
> did it again and it says "(Incomplete)".  Maybe that doesn't actually mean
> it tried twice though, I'm not sure.
>
>
>>
>> I've pushed
>>
>> https://github.com/bestpractical/rt/commit/0ac64855f479b4133f4fe838af6b8b2dec8f5d18.patch
>> and it should be in 4.2.5.  You may be able to apply the patch
>> manually to /usr/share/request-tracker4/etc/upgrade/4.1.1/schema.Pg
>> or just clean out your DB by hand before letting the debian upgrade
>> scripts go.
>>
>
> Can I safely just drop  the table, drop the sequence, create the sequence,
> and create the table?  I won't lose anything critical by doing that?
>
> I'm guessing there's a bunch of stuff it was supposed to do after that,
> but it probably stopped at that point.  I'm just thrown off by it being in
> the "upgrade history" twice, the first time it looks like it did a whole
> bunch of stuff successfully, including this step and lot after this step.
>
> -kevin
>>
>> >  Processing 4.1.1
>> >
>> > Now populating database schema.
>> >
>> > [12453] [Wed May 21 03:19:36 2014] [critical]: DBD::Pg::st execute
>> failed:
>> > ERROR:  cannot drop sequence objectscrips_id_seq because other objects
>> > depend on it
>> >
>> > DETAIL:  default for table objectscrips column id depends on sequence
>> > objectscrips_id_seq
>> >
>> > HINT:  Use DROP ... CASCADE to drop the dependent objects too. at
>> > /usr/share/request-tracker4/lib/RT/Handle.pm line 529.
>> > (/usr/share/request-tracker4/lib/RT.pm:394)
>> >
>> > DBD::Pg::st execute failed: ERROR:  cannot drop sequence
>> > objectscrips_id_seq because other objects depend on it
>> >
>> > DETAIL:  default for table objectscrips column id depends on sequence
>> > objectscrips_id_seq
>> >
>> > HINT:  Use DROP ... CASCADE to drop the dependent objects too. at
>> > /usr/share/request-tracker4/lib/RT/Handle.pm line 529.
>> >
>> > error encountered processing
>> > /usr/share/dbconfig-common/scripts/request-tracker4/upgrade/pgsql/4.2.3:
>> >
>> > /usr/share/dbconfig-common/scripts/request-tracker4/upgrade/pgsql/4.2.3
>> > exited with non-zero status
>> >
>> >
>> > There could be an issue with the Debian packages (they are still in the
>> > testing branch), but I'm trying to figure out what state the database
>> is in
>> > now.  The system is working fine, and shows version 4.2.3.  If I
>> navigate
>> > to Admin -> Tools -> System Configuration, then in the "RT Upgrade
>> History"
>> > section it looks like it might have tried to upgrade the database twice,
>> > and the second time it failed (understandably).
>> >
>> >
>> > Is there a way I can verify that the database schema is completely up to
>> > date?
>> >
>> >
>> > Here is what the "RT Upgrade History" section shows: (Sorry for the
>> HTML,
>> > wasn't sure how else to show it)
>> > RT (Current version: 4.2.3) ActionDateElapsedRT VersionInsert from
>> > /usr/share/request-tracker4/etc/upgrade/4.0.9/contentTue May 20 23:17:45
>> > 20141 second4.2.3Insert from
>> > /usr/share/request-tracker4/etc/upgrade/4.0.18/contentTue May 20
>> 23:17:53
>> > 20141 second4.2.3Insert from
>> > /usr/share/request-tracker4/etc/upgrade/4.0.19/contentTue May 20
>> 23:17:55
>> > 20140 seconds4.2.3 <http://rt/Admin/Tools/Configuration.html#>Upgrade
>> from
>> > 4.0.19 to 4.2.3Tue May 20 23:17:56 20142 minutes4.2.3Insert from
>> > /usr/share/request-tracker4/etc/upgrade/4.0.9/contentTue May 20 23:19:29
>> > 20140 seconds4.2.3Insert from
>> > /usr/share/request-tracker4/etc/upgrade/4.0.18/contentTue May 20
>> 23:19:34
>> > 20140 seconds4.2.3Insert from
>> > /usr/share/request-tracker4/etc/upgrade/4.0.19/contentTue May 20
>> 23:19:35
>> > 20140 seconds4.2.3 <http://rt/Admin/Tools/Configuration.html#>Upgrade
>> from
>> > 4.0.19 to 4.2.3 (Incomplete)Tue May 20 23:19:36 20144.2.3Upgrade from
>> > 4.0.19 to 4.1.0Tue May 20 23:19:36 20140 seconds4.2.3Insert from
>> > /usr/share/request-tracker4/etc/upgrade/4.1.0/contentTue May 20 23:19:36
>> > 20140 seconds4.2.3Upgrade from 4.1.0 to 4.1.1 (Incomplete)Tue May 20
>> > 23:19:36 20144.2.3Schema updates from
>> > /usr/share/request-tracker4/etc/upgrade/4.1.1 (Incomplete)Tue May 20
>> > 23:19:36 20144.2.3
>> > Thanks,
>> > Nate
>>
>>
>> --
>> RT Training - Boston, September 9-10
>> http://bestpractical.com/training
>>
>
> Thanks,
> Nate
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20140521/781b8c25/attachment.htm>