Hi List,
Since we also have performance Issues with Postgres and the initial
Reason why we used Postgres is not valid any more,
is there a way to go from Postgres to MySQL without loosing information
and Tickets? (with rt3)?
thx, lG uk
Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien
Network Security Universitaetsstrasse 7, 1010 Wien, Austria
eMail: ulrich.kiermayr@univie.ac.at Tel: (+43 1) 4277 / 14104
Hotline: security.zid@univie.ac.at Fax: (+43 1) 4277 / 9140
GPG Key fingerprint = BF0D 5749 4DC1 ED74 AB67 7180 105F 491D A8D7 64D8
It may be worth trying the 3.0.3 pre-release before ditching postgres.
The latest version may significantly speed things up.
-jOn Fri, May 30, 2003 at 09:25:23AM +0200, Ulrich Kiermayr wrote:
Hi List,
Since we also have performance Issues with Postgres and the initial
Reason why we used Postgres is not valid any more,
is there a way to go from Postgres to MySQL without loosing information
and Tickets? (with rt3)?
thx, lG uk
Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien
Network Security Universitaetsstrasse 7, 1010 Wien, Austria
eMail: ulrich.kiermayr@univie.ac.at Tel: (+43 1) 4277 / 14104
Hotline: security.zid@univie.ac.at Fax: (+43 1) 4277 / 9140
GPG Key fingerprint = BF0D 5749 4DC1 ED74 AB67 7180 105F 491D A8D7 64D8
rt-devel mailing list
rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel
Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.
Hi List,
Since we also have performance Issues with Postgres and the initial
Reason why we used Postgres is not valid any more,
is there a way to go from Postgres to MySQL without loosing information
and Tickets? (with rt3)?
You can copy the table contents almost directly. Postgres uses sequences
to generate primary keys while Mysql uses its auto_increment feature, so
you have to fix the result somewhat.
Going mysql->postgres is slightly more expensive if you have binary
attachments as Postgres doesn’t like to store NUL-Bytes.
On a related topic: did anybody profile RT ?
On my system (PIII 550MHz) the perl code eats about 60% of the CPU
while Postgres only accounts for the remaining 30%. Creating a new
ticket takes 1.5-2 seconds and is CPU-bound.
Going to mysql ‘should’ only help for these 30% unless there is
very inefficient Postgres specific code in RT.
Greetings,
,eM"“=. a”-. Michael van Elst
dWWMWM" - :GM==; mlelstv@dev.de.cw.net
:WWMWMw=–. "W=’ cable & wireless
9WWMm==-.
“-Wmw-” CABLE & WIRELESS
Jesse Vincent wrote:
It may be worth trying the 3.0.3 pre-release before ditching postgres.
The latest version may significantly speed things up.
That was not a good Idea: all the Tickets disappeared from the UI and
when i try to open a ticket by number I get a permission denied.
(with 3.0.2 it works well)
I can do some debuging on Monday - since I am sitting on a flakey
connection right now.
lG uk
Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien
Network Security Universitaetsstrasse 7, 1010 Wien, Austria
eMail: ulrich.kiermayr@univie.ac.at Tel: (+43 1) 4277 / 14104
Hotline: security.zid@univie.ac.at Fax: (+43 1) 4277 / 9140
GPG Key fingerprint = BF0D 5749 4DC1 ED74 AB67 7180 105F 491D A8D7 64D8
Hello,
That was not a good Idea: all the Tickets disappeared from the UI and
when i try to open a ticket by number I get a permission denied.
(with 3.0.2 it works well)
I can do some debuging on Monday - since I am sitting on a flakey
connection right now.
3.0.3 seems to fix the Problem I reported earlier. But there seems to be
a Problem with Principal_Overlay.pm.
Using the version from 3.0.3pre1 always gives me Permission Denied on
all tickets, where the version from 3.0.2 does not.
Anyone seen that? - More investigation follows.
lG uk
Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien
Network Security Universitaetsstrasse 7, 1010 Wien, Austria
eMail: ulrich.kiermayr@univie.ac.at Tel: (+43 1) 4277 / 14104
Hotline: security.zid@univie.ac.at Fax: (+43 1) 4277 / 9140
GPG Key fingerprint = BF0D 5749 4DC1 ED74 AB67 7180 105F 491D A8D7 64D8
3.0.3 seems to fix the Problem I reported earlier. But there seems to be
a Problem with Principal_Overlay.pm.
Using the version from 3.0.3pre1 always gives me Permission Denied on
all tickets, where the version from 3.0.2 does not.
Yes, I’ve seen it too. I’ve reverted to 3.0.2’s Principal_Overlay.pm
and it seems to be fine.
Also, DBIx::SearchBuilder 0.83_02 seems to be broken on my Pg
installation, which is fixed by this patch.
Thanks,
/Autrijus/
— SearchBuilder.pm.orig Fri May 30 23:35:43 2003
+++ SearchBuilder.pm Fri May 30 23:34:06 2003
@@ -1299,7 +1299,7 @@
sub DESTROY {
my $self = shift;
- if( defined $self->dbh ) {
- if( $self->can(‘dbh’) and defined $self->dbh ) {
$self->Disconnect();
}
}
3.0.3 seems to fix the Problem I reported earlier. But there seems to be
a Problem with Principal_Overlay.pm.
Using the version from 3.0.3pre1 always gives me Permission Denied on
all tickets, where the version from 3.0.2 does not.
That sounds like the new ACL caching code is doing the Wrong Thing.
Can you give me more information on what you mean by “permission denied on all tickets”
as well as details of what rights you actually have (What group or role
were the rights to perform that action on tickets assoicatied with)
Yes, I’ve seen it too. I’ve reverted to 3.0.2’s Principal_Overlay.pm
and it seems to be fine.
Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.
Also, DBIx::SearchBuilder 0.83_02 seems to be broken on my Pg
installation, which is fixed by this patch.
Thanks,
/Autrijus/
— SearchBuilder.pm.orig Fri May 30 23:35:43 2003
+++ SearchBuilder.pm Fri May 30 23:34:06 2003
@@ -1299,7 +1299,7 @@
sub DESTROY {
my $self = shift;
- if( defined $self->dbh ) {
- if( $self->can(‘dbh’) and defined $self->dbh ) {
$self->Disconnect();
}
}
This was my fault. Stan’s patch was fine. I just applied it to the wrong
file. (Should have been Handle.pm)
0.83_03 is on CPAN now and should fix this.
Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.
Hi,
That sounds like the new ACL caching code is doing the Wrong Thing.
Can you give me more information on what you mean by “permission denied on all tickets”
as well as details of what rights you actually have (What group or role
were the rights to perform that action on tickets assoicatied with)
My setup is that the individual user does not have any rights in that
queue, only a group the user belongs to has the relevant rights. and the
User I tried it with has global superuser privileges.
if that does not help you enouhg, I cah go througk the .pm tomorrow and
try to isolate the problem.
lG uk
Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien
Network Security Universitaetsstrasse 7, 1010 Wien, Austria
eMail: ulrich.kiermayr@univie.ac.at Tel: (+43 1) 4277 / 14104
Hotline: security.zid@univie.ac.at Fax: (+43 1) 4277 / 9140
GPG Key fingerprint = BF0D 5749 4DC1 ED74 AB67 7180 105F 491D A8D7 64D8