upload seems a tad excessive, though maybe necessary.
*shrug* -sc
--
Sean Chittenden
relevant triggering conditions and I'll send
you the triggers/sql functions. -sc
--
Sean Chittenden
--
Sean Chittenden
management system. Let the
database manage the data. Right now dbmail is managing data because
MySQL can't. -sc
--
Sean Chittenden
). -sc
BTW, Aaron, I'll be back in SJC in a week or two, if you're interested,
we could grab coffee or a beer sometime... just noticed you're on a
connection through palo alto that mean you're local to the Bay?
--
Sean Chittenden
week or so. Which bug is the one I should look at? Bug
118 or 141? -sc
--
Sean Chittenden
is updated, it copies itself to a new message/message id and
the change cascades downwards. This would save space and IO. -sc
--
Sean Chittenden
volume). -sc
cd ~/open_source/pgsql/contrib/pg_autovacuum
gmake
gmake install
--
Sean Chittenden
that
you insert this data into will enforce that. -sc
--
Sean Chittenden
tables still need to have
INDEXes added and need to be ANALYZEd (not that it's applicable in this
case, but still). -sc
--
Sean Chittenden
efficient, they're faster too!
http://www.postgresql.org/docs/7.4/static/sql-declare.html
http://www.postgresql.org/docs/7.4/static/sql-close.html
http://www.postgresql.org/docs/7.4/static/sql-fetch.html
-sc
--
Sean Chittenden
Ilja, howabout it: can we start using gc in the codebase starting at
2.0.2?
And there was *much* rejoicing :) This is good to hear. Just for
kicks, I bet you haven't noticed any slowdowns either. -sc
--
Sean Chittenden
if glib didn't let you do
the same. All said, it should take no more than about 10 lines of code
to accomplish the task of unifying the memory allocation to be
completely handled by GC. -sc
--
Sean Chittenden
--
Sean Chittenden
in that regard, though I
haven't had the time to figure out why. -sc
So nothing to worry about, eh? ;-)
That's what I keep telling myself until I figure out what's going on.
:) -sc
--
Sean Chittenden
ago, but I don't recall at all.
It was my understanding that they were caused by the same code problem,
but weren't centralized with a single coding error. Ie, the work for
pop3 needs to be duplicated for imapd. -sc
--
Sean Chittenden
and fast (ie, they're used in
the kernel).
But I'm still unable to reproduce this bug, which makes it rather
difficult to track down.
Send me a patch, I can reproduce this problem in seconds with OS-X's
Mail.app. -sc
--
Sean Chittenden
? Please, please test it.
I don't use pop3 and haven't had any problems with pop3, yet. :) -sc
--
Sean Chittenden
-imapsession.c
before I ran out of time with this. I'll post the patch in a few hours
once I finish sweeping through the tree. -sc
--
Sean Chittenden
(mark a-t orcon.net.nz) or to the list.
Eh, I figure someone else may find it useful.
--
Sean Chittenden
for dbmail not to return code 67 in this case?
*hopes not* Having this fixed and returning the right data would be
really spiffy, IMHO. -sc
--
Sean Chittenden
out on my TODO list for a week or two. That said, thank you for
figuring this out: this is exactly what's going on...
. It's
--
Sean Chittenden
at this
point. I've found the latest CVS to be very stable (with the exception
of
this bug) and much faster, especially for searching. Great work! So...
Ilja, you around?
Has the infinite loop IMAP problem been fixed? Last I checked it was
still there. -sc
--
Sean Chittenden
IMAP server. :)
-sc
--
Sean Chittenden
.
Is there any reason foreign keys have been removed from the schema? Or
can I send a patch in that adds them back for the schema? Foreign keys
are great anti-foot shooting measures. -sc
--
Sean Chittenden
those segfaults come from after running the
code throught valgrind. I'll fix it asap.
Oh, too cool. :) I'm really excited to hear that. -sc
--
Sean Chittenden
(messageblk_idnr)
PRIMARY KEY (user_idnr)
PRIMARY KEY (user_idnr)
PRIMARY KEY (idnr)
-sc
--
Sean Chittenden
Please test and test some more, because this will become 2.0.1.
Did I miss anything?
The infinite IMAP looping bug is still present in the
dbmail_2_0_branch. -sc
--
Sean Chittenden
IP [a.b.c.d]
dbmail.txt.bz2
Description: Binary data
--
Sean Chittenden
,
timeoutMsg = 0x41ba58 * BYE dbmail IMAP4 server signing off due to
timeout\r\n,
serverUser = nobody, '\0' repeats 1017 times, serverGroup =
nogroup, '\0' repeats 1016 times, ClientHandler = 0x404000
IMAPClientHandler}
--
Sean Chittenden
and it
periodically SEGV's. -sc
--
Sean Chittenden
in incinerator.
Approved by:krion
Revision ChangesPath
1.25 +3 -3 ports/mail/gmime2/Makefile
--
Sean Chittenden
longer for it to fail and it was failing much later in the process
of appending messages (was able to upload all of my Yahoo! news alerts
with gmime, but it's failing on some of my USGS bits). Just a thought.
-sc
--
Sean Chittenden
[60093]: ParentSigHandler(): got
signal [20]
Nov 9 16:24:04 mail dbmail/imap4d[60093]:
pool.c,manage_restart_children: child [60094] exited. Restarting...
--
Sean Chittenden
So, we should crib a memory pool API from someplace (IIRC, Timo
Sirainen has a good one in Dovecot that is MIT licensed) or write
our own in Glib style and send it upstream (probably a bigger
project than it needs to be).
Why? To avoid the constant free(3)'ing?
Yes, exactly. Keeping track of
/firemime/
Anyway, just something to think about. -sc
--
Sean Chittenden
Hrm... alright... any ideas/workarounds?
In case people missed it in my other message, HEAD doesn't seem to be
having this problem. -sc
--
Sean Chittenden
took the issue up with the maintainer. Sorry for the noise. -sc
--
Sean Chittenden
[EMAIL PROTECTED]
. Here's the message in
the archives.
http://mailman.fastxs.net/pipermail/dbmail-dev/2004-November/005335.html
Hope that helps, please let me know if there's anything else I can do:
this is killing me. :) -sc
--
Sean Chittenden
dbmsgbuf.c,db_update_msgbuf: update msgbuf_buf updating 131072, 3700,
583, 583
dbmsgbuf.c,db_update_msgbuf: update msgbuf: entire fit
dbmsgbuf.c,db_update_msgbuf update msgbuf succes NOMORE
db_start_msg(): exit
--
Sean Chittenden
, the difference in bytes would be
roughly the difference of the following pseudo queries: 'SELECT 4 *
COUNT(*) FROM total_num_headers' and 'SELECT SUM(LENGTH(msg_headers))
FROM all_headers'.
If someone points me in the right direction, I'll crank out the code
necessary to make that happen. -sc
--
Sean
/
-sc
--
Sean Chittenden
--
Sean Chittenden
the problem, but, -fPIC incurs a performance hit. One of
FreeBSD's libtool guru's had this to say about it:
http://lists.freebsd.org/pipermail/cvs-ports/2004-October/048091.html
Any chance this can be fixed for amd64? I'll gladly test patches. -sc
--
Sean Chittenden
[EMAIL PROTECTED]
44 matches
Mail list logo
