[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