[rt-users] Upgrade History shows Upgrade Incomplete

[Nathan Baker]

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/7cc8b87e/attachment.htm>