I have attached the bug report and number where I posted my garbage
collection patches. Enjoy.
Dan
--- Begin Message ---
A BUGNOTE has been added to this bug.
==
http://dbmail.org/mantis/bug_view_page.php?bug_id=023
===
It is time to add garbage collection. I'll submit some patches and I'll
file a bug. Btw, ask the list if they want the bug tracker mailing them.
Cheers
Dan Weber
Ilja Booij wrote:
Hans Kristian Rosbach wrote:
I was looking at pop3.c and noticed that in
'pop3_handle_connection'
we allocate
Thomas Mueller <[EMAIL PROTECTED]> said:
> "Release early, release often".
Add to that "maintain compatibility along your production branches"
> The dynamic preforking patch seems to be working? It's in the Debian
> packages as far as I know - so it could be applied to 2.0, tested and a
> new ve
mkinstalldirs will create the necessary directories for the package. It
checks to see if they already exist. mkinstalldirs does a fine job.
Dan Weber
Ilja Booij wrote:
Hans Kristian Rosbach wrote:
I do not quite understand this script, but if I
am not compretely wrong it assumes that if I
Hi Aaron,
> > There are much more important things that should be done I think:
> > - speedup of dbmail by marking mail headers, using transaction
> > - Sieve
> > - dynamic preforking
> > These changes will be delayed again.
> > Prefixes don't improve the functionality of dbmail, these changes wil
Thomas Mueller <[EMAIL PROTECTED]> said:
> There are much more important things that should be done I think:
> - speedup of dbmail by marking mail headers, using transaction
> - Sieve
> - dynamic preforking
> These changes will be delayed again.
> Prefixes don't improve the functionality of dbmail
Hans Kristian Rosbach <[EMAIL PROTECTED]> said:
[huge snip]
> But right now I would be happy enough if we just moved the headers
> out into a separate table so that it can have a different storage
> type than that of the rest of the mailbody. This would allow scaling
> better.
The headers *are* a
Hi Ilja,
> >>>for 2.0, we'd only like to see 2 changes:
> >>>1. table names prefixed with 'dbmail_'
> >>>2. command line options sane.
[..]
> Since we've violated all rules of release practise anyway, me might just
> get behind the keyboard and do it
I don't think it's a good idea to change (1.
Hans Kristian Rosbach wrote:
Will look for more if I get the time, workday is
coming to an end now (3:50).
I reported a few more now, but I suddenly remembered
that I had not checked to see wether they were only
mallocs on references passed to the function. I will
not have time to check t
> Will look for more if I get the time, workday is
> coming to an end now (3:50).
I reported a few more now, but I suddenly remembered
that I had not checked to see wether they were only
mallocs on references passed to the function. I will
not have time to check this.
-HK
> correct. These buffers should be freed. I'm on it.
I reported it in bug tracker, #15
Will look for more if I get the time, workday is
coming to an end now (3:50).
-HK
Hans Kristian Rosbach wrote:
I was looking at pop3.c and noticed that in
'pop3_handle_connection'
we allocate memory for 'buffer' and
for 'session.apop_stamp'.
But in between the allocation and the free
statements we have several return() points.
I think this translates to potential memory
leak
I was looking at pop3.c and noticed that in
'pop3_handle_connection'
we allocate memory for 'buffer' and
for 'session.apop_stamp'.
But in between the allocation and the free
statements we have several return() points.
I think this translates to potential memory
leaks, am I wrong?
-HK
I might be way off base here, but from my understanding, the following
line would import CFLAGS from the main Makefile.
"CFLAGS = @CFLAGS@"
It is lacking in 'sort/Makefile.in'. Is there a spesific reason, or is
it just missing?
I have not submitted this to the bug tracker.
-HK
Hans Kristian Rosbach wrote:
I do not quite understand this script, but if I
am not compretely wrong it assumes that if I
want to install into '/usr/mail/dbmail' then
'/usr/mail' already exists. This might be a
false assumption.
Maybe we should consider using 'mkdir -p /path/'
as this will make
I do not quite understand this script, but if I
am not compretely wrong it assumes that if I
want to install into '/usr/mail/dbmail' then
'/usr/mail' already exists. This might be a
false assumption.
Maybe we should consider using 'mkdir -p /path/'
as this will make all missing parent directories
Is there any reason for this code?
-- required tables:
CREATE TABLE aliases_1 AS SELECT * FROM aliases;
CREATE TABLE users_1 AS SELECT * FROM users;
CREATE TABLE mailboxes_1 AS SELECT * FROM mailboxes;
CREATE TABLE messages_1 AS SELECT * FROM messages;
CREATE TABLE messageblks_1 AS SELECT * FROM m
I've been reading through the pgsql schema, and submitted
a few bugs regarding it.
Several data fields in the database are not marked
as 'NOT NULL'. Either this has been forgotten or it
is intentional (if so, I cant see why).
The ones I mean are these:
mailboxes->permission INT2 DEFAULT '2'
Pidfiles are hardcoded to /var/run/dbmail-.pid, with -p specifying
an alternative file of your choosing. It is currently a fatal error if a pid
file cannot be created, and it is also a fatal error if the pidfile already
exists and contains a valid pid:
Jul 9 02:57:51 cubit dbmail/pop3d[27138]: p
Aaron Stone wrote:
Matthew T. O'Connor said:
On Thu, 2004-07-08 at 03:43, Ilja Booij wrote:
"This all works for me, we want 2.0, let's bring out a Release
Candidate". And after that, things turned out to be broken and
we had to change a lot of things..
[snip]
I agree they
Hans Kristian Rosbach wrote:
Hi, while makeing my webmail application I
noticed a potential slowness.
In the database, the aliases->deliver_to
is stored as varchar(250) but only contains
integers (user ids) to whom it should be
delivered to. This can be very non-optimal
when the aliases table b
Hi, while makeing my webmail application I
noticed a potential slowness.
In the database, the aliases->deliver_to
is stored as varchar(250) but only contains
integers (user ids) to whom it should be
delivered to. This can be very non-optimal
when the aliases table becomes BIG.
I assume the reason
I have a funny feeling that there's a default handler for SIGCHLD on some
platforms that kills the children. Reading the fork(3) manpage, though,
indicates that children remain zombies after their deaths until the parent
asks for their exit status / return code. The implication is that if the
paren
Strange, on my 2.0 setup, if I kill the parent, all the children die.
Aaron Stone wrote:
Ok, we're both wrong. Children do have to be killed individually, and so the
pids do all need to be recorded. [snip]
24 matches
Mail list logo
