Upgrade History shows Upgrade Incomplete

RT Users
1

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:

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

2

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?

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.

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.

-kevin

3

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

4

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,
NateOn Wed, May 21, 2014 at 4:23 PM, Nathan Baker bakern@gmail.com wrote:

On Wed, May 21, 2014 at 1:22 PM, Kevin Falcone falcone@bestpractical.comwrote:

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

5 
 > 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.Â

I find that surprising, since you had a 4.2 only table.

 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.

oh.
You cannot safely upgrade RT like that.

Restore from a backup and upgrade cleanly.

I wouldn’t trust a database that had run the upgrades twice.

-kevin

6 
 > 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.?

I find that surprising, since you had a 4.2 only table.

 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.

oh.
You cannot safely upgrade RT like that.

Restore from a backup and upgrade cleanly.

I wouldn’t trust a database that had run the upgrades twice.

Ah, I had always assumed that updates were idempotent. Sounds like
we need to adjust the error handling in the Debian package then.
(What I think happened in Nathan’s case was that the upgrade itself
went okay but something else went wrong in the package postinst).

Dominic Hargreaves, Systems Development and Support Section
IT Services, University of Oxford, 13 Banbury Road, Oxford, OX2 6NN

signature.asc (198 Bytes)

7

oh.
You cannot safely upgrade RT like that.

Restore from a backup and upgrade cleanly.

I wouldn’t trust a database that had run the upgrades twice.

You’re right, that would be the safest. I’ve been running it in production
for 1-2 days now though, with no errors or noticeable issues, so I think
I’m just going to leave it. Thanks to the new “RT upgrade history”, I can
see which steps attempted to run twice before it failed the second time. I
looked at all of those changes, and I don’t see anything in there that
would cause any problems with the data or schema. The steps that ran a
second time are:

Insert from /usr/share/request-tracker4/etc/upgrade/4.0.9/content
Insert from /usr/share/request-tracker4/etc/upgrade/4.0.18/content
Insert from /usr/share/request-tracker4/etc/upgrade/4.0.19/content
Insert from /usr/share/request-tracker4/etc/upgrade/4.1.0/content

So I think I got lucky that it failed right after that before getting any
further :)On Fri, May 23, 2014 at 6:13 AM, Dominic Hargreaves < dominic.hargreaves@it.ox.ac.uk> wrote:

Ah, I had always assumed that updates were idempotent. Sounds like
we need to adjust the error handling in the Debian package then.
(What I think happened in Nathan’s case was that the upgrade itself
went okay but something else went wrong in the package postinst).

The first thing that failed during the upgrade process was the database
backup. Peer authentication for user “postgres” failed. I’m not sure if
it ever worked on this system, but RT was installed originally using Debian
packages. I had backed up the database manually before starting just to be
safe. Running “passwd postgres” and setting a password for that user got
peer authentication working.

During the database upgrade part, I’m not sure why it was failing to
perform the upgrade. Finally after I selected “retry” and then answered
“No” when asked to use dbconfig to upgrade the database (I was going to do
it manually at that point), it actually started performing the database
upgrade, but from what I can tell it tried to do it twice.

I’m not ruling out that I did something wrong, but if you have anything you
want me to check on this system let me know. I have the apt term.log yet
which shows what was done, but unfortunately won’t show what answers I
chose during the process. When the RT 4.2.4 package gets to testing I will
try that one and let you know if I have any issues.

Thanks!
Nate