Nicola Ranaldo wrote:
But another main reason is that I hold in the same database user passwords
and other accounting informations, imp prefs/addressbook, and all my
sendmail maps (Yes! also virtusertable!).
Hello,
that sounds interesting for me! Did you patch sendmail to read its maps
out fr
> That being said, I really think that using an RDBMS for the simple
> key/value pairings that cyrus needs is really unnecessary and reeks of "I
> want to use a buzzword" more than being a real solution.
>
> -Rob
Oh! finally a negative response :)
Howewer this solution is *real* for me, I solved a
>I really don't know... This buffer is in the daemon?
This would be in the client.
>Don't you have to receive responses from the SQL DB? Or these commands
>are only writes (UPDATE, INSERT)? If these are only writes it seams a
>good ideia, but if you need to SELECT (inside the transaction) too the
> -Original Message-
> From: Nuno Silva [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, November 30, 2002 2:50 AM
> To: Nicola Ranaldo
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: PostgreSQL backend: a waste of time?
>
>
> Hello!
>
> Nicola R
Stanford CA, 94305
[EMAIL PROTECTED]
- Original Message -
From: "Rob Siemborski" <[EMAIL PROTECTED]>
To: "Nuno Silva" <[EMAIL PROTECTED]>
Cc: "Nicola Ranaldo" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Friday,
On Sat, 30 Nov 2002, Nuno Silva wrote:
> In most scenarious I agree 100% :) However if you have a busy server and
> you want a remote server to take care of retreiving, inserting, sorting,
> etc, RDBMS is the answer. This will add a new server to your setup, so
> it's a Bad Thing(c) too :))
It wi
Hello!
Rob Siemborski wrote:
All cyrusdb backends need to support transactions.
That being said, I really think that using an RDBMS for the simple
key/value pairings that cyrus needs is really unnecessary and reeks of "I
want to use a buzzword" more than being a real solution.
In most scena
On Sat, 30 Nov 2002, Nuno Silva wrote:
> I'm not 100% sure, but I suppose that one can virtualize the
> connections. What I mean is: imapd (or pop3d or lmtpd...) wants to write
> something -> ask the daemon and the daemon will choose a free connection
> and commit those changes. This is the "one o
Hello!
Nicola Ranaldo wrote:
I cannot spread sql commands of a unique transaction over multiple pgsql
connection, and a connection cannot handle parallel transactions.
So if i have 1000 imapd process starting a transaction the mailbox daemon
has to open 1000 pgsql connection.
Reading from the D
On Fri, 29 Nov 2002, Nicola Ranaldo wrote:
> Howewer i think a pgsql connection for every master child could not be a
> problem, on my production server (7500 very active users, cyrus.log is
> 20MB/day) the average number of imapd is 15, pop3d is 30, lmtpd is 5 (under
> mail-bombing lmtpd process
I cannot spread sql commands of a unique transaction over multiple pgsql
connection, and a connection cannot handle parallel transactions.
So if i have 1000 imapd process starting a transaction the mailbox daemon
has to open 1000 pgsql connection.
One solution could be:
BEGIN -> Allocate a new buff
And I have done a port to imapd 2.1.9 and UDP instead of unix socket for
those who are interrested !!!
> -Original Message-
> From: Nuno Silva [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, November 27, 2002 5:01 AM
> To: [EMAIL PROTECTED]
> Subject: Re: PostgreSQL backend:
Nuno Silva wrote:
Just searched a bit and found a reference to the mailbox-daemon here:
http://asg.web.cmu.edu/archive/message.php?mailbox=archive.info-cyrus&msg=8712
Just found the URL:
http://opensource.prim.hu/mbdaemon/
Regards,
Nuno Silva
Hi!
Nicola Ranaldo wrote:
I use PostgreSQL because it's very stable on True64 (!), and there is an
historic consolidation of transactions and referential integrity.
These make MySQL immature for my purpose! Howewer at first look it seems
porting C code from PostgreSQL to MySQL is very easy :)
I
Nicola Ranaldo wrote:
in imapd.c I read:
/*
* run once when process is forked;
* MUST NOT exit directly; must return with non-zero error code
*/
int service_init(int argc, char **argv, char **envp)
but mboxlist_init() is a void! it calls directly fatal() and so exit().
Master will not chec
I use cyrus since version 2, on Linux Slackware and True64 from 4.0f to
5.1a. There are no big problems on Intel architecture, but every upgrade on
alpha was a war! For example since version 2.1.5 to compile it you have to
manually define HAVE_GETADDRINFO and in mpool.c you would apply:
(Thanks to
I use PostgreSQL because it's very stable on True64 (!), and there is an
historic consolidation of transactions and referential integrity.
These make MySQL immature for my purpose! Howewer at first look it seems
porting C code from PostgreSQL to MySQL is very easy :)
Nicola Ranaldo
> Hy!
>
> I
for those who are interrested here is a patch for Mysql as a backend.
warning, it's a developpment version for now.
> -Original Message-
> From: Noll Janos [mailto:[EMAIL PROTECTED]]
> Sent: Monday, November 25, 2002 4:36 PM
> To: [EMAIL PROTECTED]
> Subject: RE: P
On 25 Nov 2002, Erik Enge wrote:
> I wouldn't rate it as easy unless it was a config option at run-time,
> not an option to configure at compile-time.
This wouldn't be tremendously hard to do (probably just a matter of
replacing some macros with some code that is a bit more clever), but
there'd b
Ken Murchison <[EMAIL PROTECTED]> writes:
> All of the db stuff _is_ isolated in the cyrusdb layer. That's why it
> is so easy to switch between flat/skiplist/berkeley.
I wouldn't rate it as easy unless it was a config option at run-time,
not an option to configure at compile-time.
Erik.
On Mon, 25 Nov 2002 10:04:03 -0600
[EMAIL PROTECTED] wrote:
> Seems kinda ironic in a way---doesn't MySQL use BerkeleyDB? I guess
> it's all in the indexing/caching
yes, it is one of the choices for table type. others are MyISAM and
InnoDB, the latter supports transactions and is as fast as
> Alessandro Oliveira wrote:
>
> I think that all the code that is dependent on a particular database
> should be completely isolated, making it simpler to port to new
All of the db stuff _is_ isolated in the cyrusdb layer. That's why it
is so easy to switch between flat/skiplist/berkeley.
Noll Janos wrote:
Hy!
I think that's a very good idea, but we found that MySQL is much faster
than Postgres, when there are no complex queries (this is the case here),
so it might be a better idea to use MySQL.
Or better yet, support both.
Some people already use a SQL database (Postgres, in
I think that all the code that is dependent on a particular database
should be completely isolated, making it simpler to port to new
databases, for instance: Nicola likes postgres, you like mysql, and I
love oracle (besides it is very expensive), somebody else would like an
interbase or a sapdb
--On Monday, November 25, 2002 4:36 PM +0100 Noll Janos
<[EMAIL PROTECTED]> wrote:
| I think that's a very good idea, but we found that MySQL is much faster
| than Postgres, when there are no complex queries (this is the case here),
| so it might be a better idea to use MySQL.
Seems kinda ironi
Hy!
I think that's a very good idea, but we found that MySQL is much faster
than Postgres, when there are no complex queries (this is the case here),
so it might be a better idea to use MySQL.
On 25-Nov-2002 Nicola Ranaldo wrote:
> Due to our historical problems using BerkeleyDB4 over True64Uni
I have the same point of view, could you please share with me your
experiences with cyrus, and a more detailed information about your project ?
Nicola Ranaldo wrote:
Due to our historical problems using BerkeleyDB4 over True64Unix I'm coding
a
PostgreSQL backend.
It's in alpha stage and seems to
27 matches
Mail list logo
