I was thinking about the Opteron / MD5 problem, and went Googling to see what
I could see. I found a note in the changelog of Curl about some MD5 and 64-bit
something that was fixed in a late December version of Curl.
Curl uses the RSA implementation of MD5, which carries a notice that derived
wo
Thomas Mueller wrote:
Hi Chris,
My statement was meant to say that the MyISAM table handler will just
disregard BEGIN and COMMIT statements, just as it parses but ignores
CHECK and FOREIGN KEY constraints in table creation, thus illustrating
that you wouldn't need to add a mysql-with-transa
Hi Chris,
> > > My statement was meant to say that the MyISAM table handler will just
> > > disregard BEGIN and COMMIT statements, just as it parses but ignores
> > > CHECK and FOREIGN KEY constraints in table creation, thus illustrating
> > > that you wouldn't need to add a mysql-with-transaction
Several of my clients use DBMail with mail loads ranging from small (a
few users) to massive (100s of users). We use MySQL 4.0.x (x >= 13) in
all of these places and haven't noticed any corruption but that says
nothing about what you've experienced as the two loads are very, very
different to say t
No, aspseek doesn't use transactions as mysql 3.23 in the standard
distro doesn't have them.
The version I wrote for postgres does however.
I'm not sure if the mysql mailing lists was consulted, but it was a
known problem on the aspseek mailing lists.
... John
-Original Message-
From: [E
Hmm... no direct linking to SourceForge tracker items? Silly SourceForge.
http://sourceforge.net/projects/dbmail and then Patches and there it is.
Aaron
""Igor Olemskoi"" <[EMAIL PROTECTED]> said:
> link to dbmail-cvs-rc2-fixes.patch.gz doesn't work
>
> > Just posted a big cumulative patch t
Hmm...does ASPSeek utilise transactions at all?
The fact that it happened with both points to some glaring bug inside
MySQL's upper layers or a hardware problem, but since PostgreSQL was
fine (I'm assuming on the same hardware), that's a totally discounted
possibility.
Did anyone on the MySQL mai
We tried both innodb and myisam with the same results, except of course
performance suffered when using the innodb type. However both types
resulted in corrupted tables after a few days starting from scratch.
Following that corruption happened daily.
I abandoned mysql early last year as I rewrote
Now you've peaked my curiosity!
Do you have any additional details regarding table types used and
whether or not the same thing occurs in the 4.0.x series?
Regards,
Chris
On Sun, 2004-02-15 at 21:14, John Hansen wrote:
> Download and install aspseek-1.2.10 from http://www.aspseek.org
> Run this
On Sun, 2004-02-15 at 20:36, Thomas Mueller wrote:
> Hi Chris,
>
> > > > COMMIT in MySQL is passed to the table handler. In the case of MyISAM
> > > > tables, the handler disregards the statement. For InnoDB and BDB
> > > > tables,
> > > > COMMIT acts as it does in PostgreSQL.
> > >
> > > So t
Download and install aspseek-1.2.10 from http://www.aspseek.org
Run this against mysql 3.23.49
Run it for a few days, indexing about 1million urls,
Then keep reindexing them and watch your database corrupt...
Regards,
John
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTE
Hi Chris,
> > > COMMIT in MySQL is passed to the table handler. In the case of MyISAM
> > > tables, the handler disregards the statement. For InnoDB and BDB tables,
> > > COMMIT acts as it does in PostgreSQL.
> >
> > So then we have THREE different configurations to consider, and need to be
> >
link to dbmail-cvs-rc2-fixes.patch.gz doesn't work
> Just posted a big cumulative patch that incorporates my week's projects
> including delivery status notification structures, getopt support in
> dbmail-smtp (including "-f return_path"), db_get_result{int, bool, u64}
> functions and its usage th
MySQL 3.23.x does have transactions in the MAX version through the
InnoDB and BDB table types (and Gemini if you can find it anywhere).
InnoDB ships standard with MySQL 4.0.x and BDB is included in the MAX
version.
Of course, if you compile from the source, you can choose transactional
table typ
The keywords are ignored, with one small exception:
If you have a transaction that updates both InnoDB/BDB tables and MyISAM
tables, a ROLLBACK statement will result in a warning message.
Regards,
Chris
On Sun, 2004-02-15 at 17:38, Aaron Stone wrote:
> The only question is if the keywords BEGIN
Table corruptions?
I'd be very interested to hear the story around your grief, if for
nothing else, for reference purposes. :-)
Regards,
Chris
On Sun, 2004-02-15 at 17:19, John Hansen wrote:
> Personally, I recent the statement; 'Considering MySQL has proven itself
> time and time again in term
Also,...
If I have offended you in anyway, I apologise.
It was not my intention.
... John
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Aaron Stone
Sent: Sunday, February 15, 2004 5:48 PM
To: dbmail-dev@dbmail.org
Subject: RE: [Dbmail-dev] some speed
Indeed I should have used a different word.
Mind you I didn't start this thread or state that mysql isn't a real
database,. I simply responded to what I saw as words of praise where
they in my opinion aren't warranted.
But everyone has a right to their own oppinion, and I say good on them
for tho
I think you can disagree with the statement without resenting it...
My experience with MySQL has been phenominal speed *and* reliability, though
at the expense of some pretty useful SQL features. If you've had trouble with
it, you can easily get lots of help from this list and others just by askin
The only question is if the keywords BEGIN and COMMIT are ignored or if they
generate an error. In the former case, no problems. In the latter case, we
have to either drop support for certain configurations or code around them.
Aaron
"John Hansen" <[EMAIL PROTECTED]> said:
> I assume here that
Personally, I recent the statement; 'Considering MySQL has proven itself
time and time again in terms of reliability, licencing flexibility and
performance, such statements are baseless regardless of what arguments
you make for which features'; based on experience, mysql proved that it
was not reli
I assume here that you talk about MySQL 4.
MySQL 3 does not have transactions.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Chris Nolan
Sent: Sunday, February 15, 2004 11:57 AM
To: dbmail-dev@dbmail.org
Subject: Re: [Dbmail-dev] some speed tests
Forgi
Dear Aaron,
My comments are also inline. :-)
On Sun, 2004-02-15 at 12:27, Aaron Stone wrote:
> Comments inline...
>
> Chris Nolan <[EMAIL PROTECTED]> said:
>
> > Forgive the bluntness of the statement, but why is anyone even worrying
> > about transactions as they relate to MySQL???
>
> Becau
Comments inline...
Chris Nolan <[EMAIL PROTECTED]> said:
> Forgive the bluntness of the statement, but why is anyone even worrying
> about transactions as they relate to MySQL???
Because we are currently structured to have a single set of mid-level database
operations that are translated into s
Forgive the bluntness of the statement, but why is anyone even worrying
about transactions as they relate to MySQL???
COMMIT in MySQL is passed to the table handler. In the case of MyISAM
tables, the handler disregards the statement. For InnoDB and BDB tables,
COMMIT acts as it does in Postgre
I don't even know where to begin in terms of designing the delivery chain
around transactions. Could we do it as simply as adding functions...
void db_begin_transaction(void);
void db_flush_transaction(void); (or db_commit_...?)
and then calling these functions before and after each major
26 matches
Mail list logo
