Re: [rt-users] Problems upgrading from 3.9.3
On Tue, May 28, 2013 at 5:59 PM, saxmad wrote: > Thanks to all, but especially Ruslan. > > Upgrading that perl module to the latest version did indeed fix the issue > and I was able to do a full migration from 3.6.7 to 4.0.7 on Postgresql > 9.2. > > Good to know. We're planning to updated upgrade scripts so they throw more meaningful errors in this situation. We can not bump dependency for all users on Pg. > > > -- > View this message in context: > http://requesttracker.8502.n7.nabble.com/Problems-upgrading-from-3-9-3-tp53543p54053.html > Sent from the Request Tracker - User mailing list archive at Nabble.com. > > > -- > RT Training in Seattle, June 19-20: http://bestpractical.com/training > -- Best regards, Ruslan. -- RT Training in Seattle, June 19-20: http://bestpractical.com/training
Re: [rt-users] Problems upgrading from 3.9.3
Thanks to all, but especially Ruslan. Upgrading that perl module to the latest version did indeed fix the issue and I was able to do a full migration from 3.6.7 to 4.0.7 on Postgresql 9.2. -- View this message in context: http://requesttracker.8502.n7.nabble.com/Problems-upgrading-from-3-9-3-tp53543p54053.html Sent from the Request Tracker - User mailing list archive at Nabble.com. -- RT Training in Seattle, June 19-20: http://bestpractical.com/training
Re: [rt-users] Problems upgrading from 3.9.3
On 17 May 2013, at 10:45, Ruslan Zakirov wrote: On Fri, May 17, 2013 at 6:37 PM, saxmad wrote: I'm on Postgres 9.2 on Debian Wheezy. So is this a Postgres issue or an RT upgrade issue ? Both. RT uses something that is deleted. Pg deleted something that is used by software. More precisely, they removed something from a system catalog -- the spclocation column in the description of tablespaces -- which was statically set at tablespace creation time and could be invalidated silently by an innocent & plausible admin oversight, and replaced the functionality with something else -- the pg_tablespace_location() function -- which provides the same information determined dynamically at runtime. Note that the internal structure of Pg system catalogs is an area where software developers and sysadmins should expect to find change across major releases and this was a well-documented change with public discussion before it was made and during the 9.2 beta period. IOW: A documented change in Pg 9.2 fixed a design error that needed fixing. The OPERATIONALLY focused answer is simpler: You must update the Perl module DBD::Pg to v2.19.3 to get compatibility with PostgreSQL 9.2 and later. -- RT Training in Seattle, June 19-20: http://bestpractical.com/training
Re: [rt-users] Problems upgrading from 3.9.3
On Fri, May 17, 2013 at 8:04 PM, saxmad wrote: > Hmm, so is there a workaround/fix for this from either side, or is 9.2 not > really supported fully ? I have had 9.2 running fine on a completely fresh > install of RT 4.0.7. Would it better to go back to PG 9.1 to get this > upgrade sorted ? > > Thanks for all the help so far ... > > I've checked DBD::Pg's git repository. Problem is actually in that module and you're lucky. It's been fixed in 2.19.3 (the latest from the CPAN), but was not mentioned in the changelog. Upgrade the module and try again. -- > View this message in context: > http://requesttracker.8502.n7.nabble.com/Problems-upgrading-from-3-9-3-tp53543p53909.html > Sent from the Request Tracker - User mailing list archive at Nabble.com. > > > -- > RT Training in Seattle, June 19-20: http://bestpractical.com/training > -- Best regards, Ruslan. -- RT Training in Seattle, June 19-20: http://bestpractical.com/training
Re: [rt-users] Problems upgrading from 3.9.3
Few weeks ago I had exactly same issue during upgrade from 3.8.13 to 4.0.10. Because I didn't find root cause of this issue I had to install PG 9.1 temporarily (on other virtual machine) then import DB from PG 9.2.x, upgrade and then export back to 9.2.x. Best regards, Pavel Pavel Šidlo - LinuxBox.cz, s.r.o. 28. října 168, 709 00 Ostrava tel.: +420 591 166 234 mob.: +420 737 238 334 web:www.linuxbox.cz mobil servis: +420 737 238 656 email servis: ser...@linuxbox.cz - |> | Od:| |> >--| |saxmad | >--| |> | Komu: | |> >--| |rt-users@lists.bestpractical.com, | >--| |> | Datum: | |> >--| |05/17/2013 18:05 | >--| |> | Předmět: | |> >--------------| |Re: [rt-users] Problems upgrading from 3.9.3 | >--| Hmm, so is there a workaround/fix for this from either side, or is 9.2 not really supported fully ? I have had 9.2 running fine on a completely fresh install of RT 4.0.7. Would it better to go back to PG 9.1 to get this upgrade sorted ? Thanks for all the help so far ... -- View this message in context: http://requesttracker.8502.n7.nabble.com/Problems-upgrading-from-3-9-3-tp53543p53909.html Sent from the Request Tracker - User mailing list archive at Nabble.com. -- RT Training in Seattle, June 19-20: http://bestpractical.com/training <><> -- RT Training in Seattle, June 19-20: http://bestpractical.com/training
Re: [rt-users] Problems upgrading from 3.9.3
Hmm, so is there a workaround/fix for this from either side, or is 9.2 not really supported fully ? I have had 9.2 running fine on a completely fresh install of RT 4.0.7. Would it better to go back to PG 9.1 to get this upgrade sorted ? Thanks for all the help so far ... -- View this message in context: http://requesttracker.8502.n7.nabble.com/Problems-upgrading-from-3-9-3-tp53543p53909.html Sent from the Request Tracker - User mailing list archive at Nabble.com. -- RT Training in Seattle, June 19-20: http://bestpractical.com/training
Re: [rt-users] Problems upgrading from 3.9.3
On Fri, May 17, 2013 at 6:37 PM, saxmad wrote: > I'm on Postgres 9.2 on Debian Wheezy. > > So is this a Postgres issue or an RT upgrade issue ? > Both. RT uses something that is deleted. Pg deleted something that is used by software. > -- > View this message in context: > http://requesttracker.8502.n7.nabble.com/Problems-upgrading-from-3-9-3-tp53543p53907.html > Sent from the Request Tracker - User mailing list archive at Nabble.com. > > > -- > RT Training in Seattle, June 19-20: http://bestpractical.com/training > -- Best regards, Ruslan. -- RT Training in Seattle, June 19-20: http://bestpractical.com/training
Re: [rt-users] Problems upgrading from 3.9.3
I'm on Postgres 9.2 on Debian Wheezy. So is this a Postgres issue or an RT upgrade issue ? -- View this message in context: http://requesttracker.8502.n7.nabble.com/Problems-upgrading-from-3-9-3-tp53543p53907.html Sent from the Request Tracker - User mailing list archive at Nabble.com. -- RT Training in Seattle, June 19-20: http://bestpractical.com/training
Re: [rt-users] Problems upgrading from 3.9.3
On Tue, May 14, 2013 at 11:27 PM, Thomas Sibley wrote: > spclocation Looks like splocation is gone in Pg 9.2: http://www.postgresql.org/message-id/1334867818.2281.15.camel@localhost.localdomain -- Best regards, Ruslan. -- RT Training in Seattle, June 19-20: http://bestpractical.com/training
Re: [rt-users] Problems upgrading from 3.9.3
On 05/14/2013 08:57 AM, saxmad wrote: > ERROR: One of initial functions failed: DBD::Pg::db table_info failed: > ERROR: column t.spclocation does not exist > LINE 11: ...t(t.spcname) AS "pg_tablespace_name", quote_ident(t.spclocat... > ^ at > /usr/share/request-tracker4/etc/upgrade/3.9.8/content line 3. What version of Pg are you running? -- RT Training in Seattle, June 19-20: http://bestpractical.com/training
Re: [rt-users] Problems upgrading from 3.9.3
The need to get this upgrade working is mounting, so I have been trying various combinations of sequences of events to try and make progress. While I still get the errors as previously when trying to run # rt-setup-database-4 --action acl --dba postgres, I decided to ignore that and carry on with the upgrade. This time, I have been able to get as far as 3.9.8 before getting any errors. This is a lot further than I have ever got before, so I'm feeling slightly more encouraged that I can get this working eventually. Anyway, the error message I now get is as follows :- <..> snip <..> Processing 3.9.8 Now populating database schema. Now inserting data. [Tue May 14 15:49:07 2013] [warning]: DBD::Pg::db table_info failed: ERROR: column t.spclocation does not exist LINE 11: ...t(t.spcname) AS "pg_tablespace_name", quote_ident(t.spclocat... ^ at /usr/share/request-tracker4/etc/upgrade/3.9.8/content line 3. (/usr/share/request-tracker4/etc/upgrade/3.9.8/content:3) Couldn't finish 'upgrade' step. ERROR: One of initial functions failed: DBD::Pg::db table_info failed: ERROR: column t.spclocation does not exist LINE 11: ...t(t.spcname) AS "pg_tablespace_name", quote_ident(t.spclocat... ^ at /usr/share/request-tracker4/etc/upgrade/3.9.8/content line 3. I'm going to try Googling about this error, but any more formal and knowledgeable response would be gratefully received. Gary -- View this message in context: http://requesttracker.8502.n7.nabble.com/Problems-upgrading-from-3-9-3-tp53543p53840.html Sent from the Request Tracker - User mailing list archive at Nabble.com. -- RT Training in Seattle, June 19-20: http://bestpractical.com/training
Re: [rt-users] Problems upgrading from 3.9.3
Spent some more time on this over the last couple of days, but still not a lot of progress, just error messages. Having cleared out any remnants of previous tests using drop database rtdb; and drop role rtuser;, I followed the latest set of instructions. I created the database using rt-setup-database-4 --action create --dba postgres which seems fine. I then try to import the dumped data file (created with the -x switch of pg_dump),a nd it gives me the following error after every CREATE command ... CREATE TABLE psql:/home/gmason/rtdb-20130425.sql:53: ERROR: role "rtuser" does not exist CREATE SEQUENCE psql:/home/gmason/rtdb-20130425.sql:66: ERROR: role "rtuser" does not exist So I try and create the rtdb role using create role rtdb; and give it login attributes and then try the import again, having first dropped the database first.The import seems to work fine, with no errors, so I continue to the next stage as instructed, which is setting up the acl's. # rt-setup-database-4 --action acl --dba postgres Working with: Type: Pg Host: localhost Name: rtdb User: rtuser DBA:postgres Now inserting database ACLs. DBD::Pg::st execute failed: ERROR: relation "classes_id_seq" does not exist at /usr/share/request-tracker4/lib/RT/Handle.pm line 439, line 1. DBD::Pg::st execute failed: ERROR: relation "classes_id_seq" does not exist at /usr/share/request-tracker4/lib/RT/Handle.pm line 439, line 1. So I'm now stumped as to how to actually get anywhere. In case it makes any difference, I am running the rt-setup-database-4 commands as the root user, but importing the data dump file as the postgres user. Can someone put me out of my misery ?? -- View this message in context: http://requesttracker.8502.n7.nabble.com/Problems-upgrading-from-3-9-3-tp53543p53710.html Sent from the Request Tracker - User mailing list archive at Nabble.com.
Re: [rt-users] Problems upgrading from 3.9.3
On Thu, Apr 25, 2013 at 1:22 PM, saxmad wrote: > I tried setting up the database as Thomas suggested, and it certainly made > a > difference. However, I did get the following errors. Should I be worried > by them, or can they be ignored, based on what I am trying to do ? > > No, they can not be ignored. What Thomas suggested just creates empty database and grants rights to rt_user, but it doesn't work as expected. ACL step doesn't grant rights as objects (tables, sequences, indexes...) are not there. What you can do is: 1) create database: rt-setup-database-4 --action create 2) upload data dump without privileges as DBA user into this new DB, see -x option of pg_dump. 3) create rt_user and grant him permissions: rt-setup-database-4 --action acl Your log should be clean of all DBD::Pg::st errors. > Working with: > Type: Pg > Host: localhost > Name: rtdb > User: rtuser > DBA:postgres > Now creating a Pg database rtdb for RT. > Done. > Now inserting database ACLs. > DBD::Pg::st execute failed: ERROR: relation "attachments_id_seq" does not > exist at /usr/share/request-tracker4/lib/RT/Handle.pm line 439, > line > 1. > DBD::Pg::st execute failed: ERROR: relation "attachments_id_seq" does not > exist at /usr/share/request-tracker4/lib/RT/Handle.pm line 439, > line > 1. > > I carried on with importing my data and ran another upgrade. This time it > got a lot further, but it still stopped early with the following text :- > > Processing 3.9.8 > Now populating database schema. > Now inserting data. > [Thu Apr 25 09:20:33 2013] [warning]: DBD::Pg::db table_info failed: ERROR: > column t.spclocation does not exist > LINE 11: ...t(t.spcname) AS "pg_tablespace_name", quote_ident(t.spclocat... > ^ at > /usr/share/request-tracker4/etc/upgrade/3.9.8/content line 3. > (/usr/share/request-tracker4/etc/upgrade/3.9.8/content:3) > Couldn't finish 'upgrade' step. > > ERROR: One of initial functions failed: DBD::Pg::db table_info failed: > ERROR: column t.spclocation does not exist > LINE 11: ...t(t.spcname) AS "pg_tablespace_name", quote_ident(t.spclocat... > ^ at > /usr/share/request-tracker4/etc/upgrade/3.9.8/content line 3. > > What can I do to get the upgrade past this point ? > > > > > -- > View this message in context: > http://requesttracker.8502.n7.nabble.com/Problems-upgrading-from-3-9-3-tp53543p53610.html > Sent from the Request Tracker - User mailing list archive at Nabble.com. > -- Best regards, Ruslan.
Re: [rt-users] Problems upgrading from 3.9.3
I tried setting up the database as Thomas suggested, and it certainly made a difference. However, I did get the following errors. Should I be worried by them, or can they be ignored, based on what I am trying to do ? Working with: Type: Pg Host: localhost Name: rtdb User: rtuser DBA:postgres Now creating a Pg database rtdb for RT. Done. Now inserting database ACLs. DBD::Pg::st execute failed: ERROR: relation "attachments_id_seq" does not exist at /usr/share/request-tracker4/lib/RT/Handle.pm line 439, line 1. DBD::Pg::st execute failed: ERROR: relation "attachments_id_seq" does not exist at /usr/share/request-tracker4/lib/RT/Handle.pm line 439, line 1. I carried on with importing my data and ran another upgrade. This time it got a lot further, but it still stopped early with the following text :- Processing 3.9.8 Now populating database schema. Now inserting data. [Thu Apr 25 09:20:33 2013] [warning]: DBD::Pg::db table_info failed: ERROR: column t.spclocation does not exist LINE 11: ...t(t.spcname) AS "pg_tablespace_name", quote_ident(t.spclocat... ^ at /usr/share/request-tracker4/etc/upgrade/3.9.8/content line 3. (/usr/share/request-tracker4/etc/upgrade/3.9.8/content:3) Couldn't finish 'upgrade' step. ERROR: One of initial functions failed: DBD::Pg::db table_info failed: ERROR: column t.spclocation does not exist LINE 11: ...t(t.spcname) AS "pg_tablespace_name", quote_ident(t.spclocat... ^ at /usr/share/request-tracker4/etc/upgrade/3.9.8/content line 3. What can I do to get the upgrade past this point ? -- View this message in context: http://requesttracker.8502.n7.nabble.com/Problems-upgrading-from-3-9-3-tp53543p53610.html Sent from the Request Tracker - User mailing list archive at Nabble.com.
Re: [rt-users] Problems upgrading from 3.9.3
On 04/24/2013 04:06 AM, saxmad wrote: > After a lot of trial and error, I think I have worked out what is going on. > > With a clean postgres database, I cannot import my dump file due to the > rtuser role not being there. > > So I initialised the database by running the rt-setup-database-4 --action > init utility to put that right. Unfortunately, part of this seems to be > setting up the initial core data, which looks like it includes the acl > table. You can have RT setup the database user and create the database by using: rt-setup-database-4 --action create,acl The "init" action is the same as "make initdb" which is the whole process for a new install. When you restore, you'll still need to tell "psql" what database you're importing into (presumably "rtdb").
Re: [rt-users] Problems upgrading from 3.9.3
After a lot of trial and error, I think I have worked out what is going on.
With a clean postgres database, I cannot import my dump file due to the
rtuser role not being there.
So I initialised the database by running the rt-setup-database-4 --action
init utility to put that right. Unfortunately, part of this seems to be
setting up the initial core data, which looks like it includes the acl
table.
Dropping the database, tables and sequences but leaving the rtuser role
intact, I can then import the dump file without any complaints. Tables etc
are created and populated, but it does not create the actual rtdb database -
\l within psql does not show an rtdb entry. I guess that initialising the
database as above would sort that, but then give me the same problem with an
pre-existing acl table.
So I think the answer to my problem is to determine exactly what the pg_dump
command is I need to extract everything from my current RT database in order
for me to be able to import it on my new server without having to initialise
the database first.
The file I am trying to import was created using pg_dump -f ${Dump_File}
rtdb.
I am aware of numerous options to pg_dump, but inexperience means I don't
know which ones to employ in order to get a dump of my RT database with full
integrity to enable a seamless import.
Can someone enlighten me as to exactly how I should use pg_dump to get my
data in a suitable format to enable me to simply import it with psql -f
datafile.sql so I can dop the upgrade cleanly ?
--
View this message in context:
http://requesttracker.8502.n7.nabble.com/Problems-upgrading-from-3-9-3-tp53543p53598.html
Sent from the Request Tracker - User mailing list archive at Nabble.com.
Re: [rt-users] Problems upgrading from 3.9.3
Kevin - I think I get what you mean. My postgres knowledge is next to
nothing, so hopefully I have got the appropriate information.
On my original 3.6.7 instance, I have the following :-
Table "public.acl"
Column | Type |Modifiers
| Description
---+---+--+-
id| integer | not null default
nextval('acl_id_seq'::regclass) |
principaltype | character varying(25) | not null
|
principalid | integer | not null
|
rightname | character varying(25) | not null
|
objecttype| character varying(25) | not null
|
objectid | integer | not null default 0
|
delegatedby | integer | not null default 0
|
delegatedfrom | integer | not null default 0
|
Indexes:
"acl_pkey" PRIMARY KEY, btree (id)
"acl1" btree (rightname, objecttype, objectid, principaltype,
principalid)
Has OIDs: no
On my new, upgraded version that is in limbo between 3.9.2 and 3.9.3, I have
the following :-
Table "public.acl"
Column |Type |Modifiers
| Storage | Stats target | Description
---+-+--+--+--+-
id| integer | not null default
nextval('acl_id_seq'::regclass) | plain| |
principaltype | character varying(25) | not null
| extended | |
principalid | integer | not null
| plain| |
rightname | character varying(25) | not null
| extended | |
objecttype| character varying(25) | not null
| extended | |
objectid | integer | not null default 0
| plain| |
creator | integer | not null default 0
| plain| |
created | timestamp without time zone |
| plain| |
lastupdatedby | integer | not null default 0
| plain| |
lastupdated | timestamp without time zone |
| plain| |
Indexes:
"acl_pkey" PRIMARY KEY, btree (id)
"acl1" btree (rightname, objecttype, objectid, principaltype,
principalid)
Has OIDs: no
So the DelegatedBy column is definately not there now.
When I looked at the acl table on a freshly imported version of the dump, I
found that it looked exactly like upgraded version, and not like the
original 3.6.7 version. I checked the dump file and the acl table was
indeed supposed to be set up using the correct formation (3.6.7 version).
Checking a bit deeper, it seems that I have two acl tables, one within the
rtdb database, and another when connected to the default postgres database.
If I look at the layout of the spurious postgres version of the acl table,
it has the 3.6.7 layout.
I don't know how this has happened, and is almost certainly the reason why
the acl table doesn't upgrade properly, as it is already effectively
upgraded before attempting the upgrade procedure.
I will clear out all traces of the rtdb database, and then check for
residual tables etc, before trying another clean import.
Thanks for hanging in there :)
--
View this message in context:
http://requesttracker.8502.n7.nabble.com/Problems-upgrading-from-3-9-3-tp53543p53596.html
Sent from the Request Tracker - User mailing list archive at Nabble.com.
Re: [rt-users] Problems upgrading from 3.9.3
On Tue, Apr 23, 2013 at 06:11:33AM -0700, saxmad wrote: > [Tue Apr 23 13:06:53 2013] [warning]: DBD::Pg::st execute failed: ERROR: > column main.delegatedby does not exist > LINE 1: SELECT main.* FROM ACL main WHERE (main.DelegatedBy > '0') ... > ^ at > /usr/share/perl5/DBIx/SearchBuilder/Handle.pm line 509, <> line 1. > (/usr/share/perl5/DBIx/SearchBuilder/Handle.pm:509) > > Firstly, seeing as it tried to do the 3.9.3 upgrade, can I assume that the > 3.9.2 upgrade did in fact go through, despite the messages ? > > Secondly, what course of action is needed to fix the 3.9.3 upgrade message ? > It seems to be related to the messages in the 3.9.2 upgrade, so maybe that > didn't got through cleanly. You have not completed 3.9.2. Show the schema of your ACL table now and show it on your 3.6.7 instance. Then restore cleanly to test run an upgrade again and show the ACL schema there. The DelegatedBy column is dropped during the 3.9.3 step, so getting an error in 3.9.2 about it missing implies something is wrong. -kevin pgp9Bp8irC_5L.pgp Description: PGP signature
Re: [rt-users] Problems upgrading from 3.9.3
Thanks for the quick response. I tried what you suggested, but got the following error in psql :- postgres=# drop index groupmembers1; ERROR: index "groupmembers1" does not exist All I can see in the database that relates to this name is as follows :- public | groupmembers | table| rtuser=arwdDxt/rtuser | public | groupmembers_id_seq | sequence | rtuser=rwU/rtuser | As far as I can ascertain, there were no manual changes to the database that would have meant the creation of an extra index such as this. Am I doing something wrong ? I thought I typed the command you suggested correctly - I tried several times to confirm this. -- View this message in context: http://requesttracker.8502.n7.nabble.com/Problems-upgrading-from-3-9-3-tp53543p53579.html Sent from the Request Tracker - User mailing list archive at Nabble.com.
Re: [rt-users] Problems upgrading from 3.9.3
Carrying on the upgrade, I have got to version 3.9.3, but with some scary
messages about 3.9.2.
Processing 3.9.2
Now inserting data.
[Tue Apr 23 13:06:53 2013] [warning]: DBD::Pg::st execute failed: ERROR:
column main.delegatedby does not exist
LINE 1: SELECT main.* FROM ACL main WHERE (main.DelegatedBy > '0') ...
^ at
/usr/share/perl5/DBIx/SearchBuilder/Handle.pm line 509, <> line 1.
(/usr/share/perl5/DBIx/SearchBuilder/Handle.pm:509)
[Tue Apr 23 13:06:53 2013] [warning]: RT::Handle=HASH(0x6d06e28) couldn't
execute the query 'SELECT main.* FROM ACL main WHERE (main.DelegatedBy >
'0') AND (main.DelegatedFrom > '0') ' at
/usr/share/perl5/DBIx/SearchBuilder/Handle.pm line 522
DBIx::SearchBuilder::Handle::SimpleQuery('RT::Handle=HASH(0x6d06e28)',
'SELECT main.* FROM ACL main WHERE (main.DelegatedBy > \'0\')...') called
at /usr/share/perl5/DBIx/SearchBuilder.pm line 235
DBIx::SearchBuilder::_DoSearch('RT::ACL=HASH(0x4bc3170)') called at
/usr/share/request-tracker4/lib/RT/SearchBuilder.pm line 343
RT::SearchBuilder::_DoSearch('RT::ACL=HASH(0x4bc3170)') called at
/usr/share/request-tracker4/lib/RT/ACL.pm line 263
RT::ACL::_DoSearch('RT::ACL=HASH(0x4bc3170)') called at
/usr/share/perl5/DBIx/SearchBuilder.pm line 503
DBIx::SearchBuilder::Next('RT::ACL=HASH(0x4bc3170)') called at
/usr/share/request-tracker4/lib/RT/ACL.pm line 228
RT::ACL::Next('RT::ACL=HASH(0x4bc3170)') called at
/usr/share/request-tracker4/etc/upgrade/3.9.2/content line 19
RT::Handle::__ANON__() called at
/usr/share/request-tracker4/lib/RT/Handle.pm line 769
eval {...} called at /usr/share/request-tracker4/lib/RT/Handle.pm line
769
RT::Handle::InsertData('RT::Handle=HASH(0x6d06e28)',
'/usr/share/request-tracker4/etc/upgrade/3.9.2/content', undef) called at
/usr/sbin/rt-setup-database-4 line 291
main::action_insert('datafile', undef, 'action', 'upgrade', 'datadir',
'/usr/share/request-tracker4/etc/upgrade/3.9.2', 'backcompat',
'ARRAY(0x2165e08)', 'dba', ...) called at /usr/sbin/rt-setup-database-4 line
397
main::action_upgrade('action', 'upgrade', 'dba', 'postgres') called at
/usr/sbin/rt-setup-database-4 line 196 (/usr/share/perl/5.10/Carp.pm:47)
[Tue Apr 23 13:06:53 2013] [crit]: _DoSearch is not so successful as it
still needs redo search, won't call _BuildHash
(/usr/share/request-tracker4/lib/RT/ACL.pm:266)
Processing 3.9.3
Now populating database schema.
[Tue Apr 23 13:06:53 2013] [crit]: DBD::Pg::st execute failed: ERROR:
column "delegatedby" of relation "acl" does not exist at
/usr/share/request-tracker4/lib/RT/Handle.pm line 515.
(/usr/share/request-tracker4/lib/RT.pm:351)
DBD::Pg::st execute failed: ERROR: column "delegatedby" of relation "acl"
does not exist at /usr/share/request-tracker4/lib/RT/Handle.pm line 515.
Firstly, seeing as it tried to do the 3.9.3 upgrade, can I assume that the
3.9.2 upgrade did in fact go through, despite the messages ?
Secondly, what course of action is needed to fix the 3.9.3 upgrade message ?
It seems to be related to the messages in the 3.9.2 upgrade, so maybe that
didn't got through cleanly.
Thanks.
--
View this message in context:
http://requesttracker.8502.n7.nabble.com/Problems-upgrading-from-3-9-3-tp53543p53581.html
Sent from the Request Tracker - User mailing list archive at Nabble.com.
Re: [rt-users] Problems upgrading from 3.9.3
I'll answer my own question - I was doing something wrong. Helps if you connect to the database first . Sorry for the noise. Will carry on with the upgrade process now. -- View this message in context: http://requesttracker.8502.n7.nabble.com/Problems-upgrading-from-3-9-3-tp53543p53580.html Sent from the Request Tracker - User mailing list archive at Nabble.com.
Re: [rt-users] Problems upgrading from 3.9.3
On Tue, Apr 23, 2013 at 2:40 PM, saxmad wrote: > [Tue Apr 23 09:58:37 2013] [crit]: DBD::Pg::st execute failed: ERROR: > relation "groupmembers1" already exists at > /usr/share/request-tracker4/lib/RT/Handle.pm line 515. > (/usr/share/request-tracker4/lib/RT.pm:351) > DBD::Pg::st execute failed: ERROR: relation "groupmembers1" already exists > at /usr/share/request-tracker4/lib/RT/Handle.pm line 515. > This scrip tries to create an index, but name is in use. We use tablename+number for indexes. I suspect you created an index yourself. Easy route is to drop it: drop index groupmembers1; And start upgrade command and enter 3.8.2 as version you're upgrading from. This case is very simple as schema file for 3.8.3 has only index and nothing else. In other cases it may be more complicated, so keep posting. Other warnings are harmless. > I'm pretty sure that I got this message at the same point last time, but I > have stopped, as requested by Kevin, and posted the error. > -- Best regards, Ruslan.
Re: [rt-users] Problems upgrading from 3.9.3
I cleaned out the first database, initialised the new database, and imported the data dump again. I managed to get to upgrading to release 3.8.3 when it fell over again with the following message :- Proceed [y/N]:y Processing 3.7.1 Now inserting data. Processing 3.7.3 Now populating database schema. Processing 3.7.10 Now inserting data. Processing 3.7.15 Now inserting data. Processing 3.7.19 Now inserting data. Processing 3.7.81 Processing 3.7.82 Now inserting data. Processing 3.7.85 Now inserting data. Processing 3.7.86 Now inserting data. Processing 3.7.87 Now inserting data. Processing 3.8.0 Now inserting data. Processing 3.8.1 Now inserting data. Processing 3.8.2 Now inserting data. [Tue Apr 23 09:58:37 2013] [warning]: Going to add [OLD] prefix to all templates in approvals queue. If you have never used approvals, you can safely delete all the templates with the [OLD] prefix. Leave the new Approval templates because you may eventually want to start using approvals. (/usr/share/request-tracker4/etc/upgrade/3.8.2/content:3) [Tue Apr 23 09:58:37 2013] [error]: That principal already has that right (/usr/share/request-tracker4/lib/RT/Handle.pm:969) [Tue Apr 23 09:58:37 2013] [warning]: IMPORTANT: We're going to delete all scrips in Approvals queue and save them in 'rt-approvals-scrips-NoKY' file. (/usr/share/request-tracker4/etc/upgrade/3.8.2/content:165) Processing 3.8.3 Now populating database schema. [Tue Apr 23 09:58:37 2013] [crit]: DBD::Pg::st execute failed: ERROR: relation "groupmembers1" already exists at /usr/share/request-tracker4/lib/RT/Handle.pm line 515. (/usr/share/request-tracker4/lib/RT.pm:351) DBD::Pg::st execute failed: ERROR: relation "groupmembers1" already exists at /usr/share/request-tracker4/lib/RT/Handle.pm line 515. I'm pretty sure that I got this message at the same point last time, but I have stopped, as requested by Kevin, and posted the error. -- View this message in context: http://requesttracker.8502.n7.nabble.com/Problems-upgrading-from-3-9-3-tp53543p53575.html Sent from the Request Tracker - User mailing list archive at Nabble.com.
Re: [rt-users] Problems upgrading from 3.9.3
On Thu, Apr 18, 2013 at 05:17:07PM +0100, Gary Mason wrote: > # rt-setup-database-4 --action upgrade --dba postgres > --prompt-for-dba-password > > That was fine for a couple of the versions, but it fell over a > couple of times at various points, and I had to resort to forcing > through those upgrades manually, usually with a command like the > following :- > > # rt-setup-database-4 --action insert --datadir > /usr/share/request-tracker4/etc/upgrade/3.8.3 --dba postgres Unfortunately - that command only completes one of 3 possible steps in that upgrade. In your case, it skipped the creation of a new PostgreSQL specific index. I'd suggest posting the first error your received from a clean restore of 3.6.7 and running the automated upgrade step. > DBD::Pg::st execute failed: ERROR: column "delegatedby" of relation > "acl" does not exist at /usr/share/request-tracker4/lib/RT/Handle.pm > line 515. This usually means you have already run this step, since that column has existed since long before 3.6.7. The column was also used in the 3.9.2 upgrade step which you say completed successfully. > Anyone have any idea how I can get the upgrade through this > particular version ? I'd start again, posting your initial errors and working from there. I wouldn't trust an upgraded database with this error, or with this many unknowns. -kevin pgppXYGbFnQLC.pgp Description: PGP signature
[rt-users] Problems upgrading from 3.9.3
HI, I am in the process of migrating my current RT to a brand new separate server running Debian/Postgresql and RT 4.0.7 installed via backports. I have managed to import the dump of the database into the new system, and have set about upgrading the database. I already have RT4.0.7 working fine with some test data I put into the initial system - just need to get the historical ticket information in now. I started out at version 3.6.7 using the following command :- # rt-setup-database-4 --action upgrade --dba postgres --prompt-for-dba-password That was fine for a couple of the versions, but it fell over a couple of times at various points, and I had to resort to forcing through those upgrades manually, usually with a command like the following :- # rt-setup-database-4 --action insert --datadir /usr/share/request-tracker4/etc/upgrade/3.8.3 --dba postgres That worked fine up to version 3.9.3. When I try to upgrade from that version, I get the following errors :- root@rta-01:/etc/request-tracker4# rt-setup-database-4 --action upgrade --dba postgres --prompt-for-dba-password In order to create or update your RT database, this script needs to connect to your Pg instance on localhost as postgres Please specify that user's database password below. If the user has no database password, just press return. Password: Working with: Type:Pg Host:localhost Name:rtdb User:rtuser DBA:postgres Enter RT version you're upgrading from: 3.9.2 Going to apply following upgrades: * 3.9.3 * 3.9.5 * 3.9.6 * 3.9.7 * 3.9.8 * 4.0.0rc2 * 4.0.0rc4 * 4.0.0rc7 * 4.0.1 * 4.0.3 * 4.0.4 * 4.0.6 Enter RT version if you want to stop upgrade at some point, or leave it blank if you want apply above upgrades: IT'S VERY IMPORTANT TO BACK UP BEFORE THIS STEP Proceed [y/N]:y Processing 3.9.3 Now populating database schema. DBD::Pg::st execute failed: ERROR: column "delegatedby" of relation "acl" does not exist at /usr/share/request-tracker4/lib/RT/Handle.pm line 515. I tried manually upgrading that version, but that failed too, with a different message :- # rt-setup-database-4 --action insert --datadir /usr/share/request-tracker4/etc/upgrade/3.9.3 --dba postgres In order to create or update your RT database, this script needs to connect to your Pg instance on localhost as postgres Please specify that user's database password below. If the user has no database password, just press return. Password: Working with: Type:Pg Host:localhost Name:rtdb User:rtuser DBA:postgres Now inserting data. Couldn't finish 'insert' step. ERROR: Couldn't load data from '/usr/share/request-tracker4/etc/upgrade/3.9.3/content' for import: ERROR:Can't locate /usr/share/request-tracker4/etc/upgrade/3.9.3/content in @INC (@INC contains: /usr/local/share/request-tracker4/lib /usr/share/request-tracker4/lib /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at /usr/share/request-tracker4/lib/RT/Handle.pm line 762. Anyone have any idea how I can get the upgrade through this particular version ? Thanks, Gary
