[rt-users] Problems upgrading from 3.9.3
saxmad
g.mason at fairfx.com
Wed Apr 24 05:11:17 EDT 2013
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.
More information about the rt-users
mailing list