Has MySQL just knowingly released a complete pile-of-shite???

A month ago today I sent in a bug report which showed that in most
circumstances 4.0.13 runs at 1/3 of the expected speed and blocks
selects on tables whilst inserts are occuring (see bug 712). This was
assigned low priority / non-critical status.... I was surprised and so I
argued for a brief time that it deserved a higher priority and then sat
patiently waiting for it to be fixed. It seemed odd to me that MySQL
seemed completely unperturbed that there was such a pitifully poorly
performing server released as a production release. Imagine my surprise
when I discovered that the bug has been fixed but was not incorporated
into 4.0.14 but instead is in the change list for 4.0.15.

I remember reading somewhere (I think on your bugs site) that all bugs
are fixed in the next release or noted in the documentation.... I
haven't checked yet, but I'm guessing the 4.0.14 documentation doesn't
mention that MyISAM tables become pitifully slow for updates & inserts
and block selects, if you decide to index them!

I have been supporter of MySQL for many years and I am now feeling very
sad :-(. Is 4.0.15 expected in the next couple of days or do you expect
the MySQL community to put up with another sub-standard release for the
obligatory month between updates?

Does anyone out there have any info on porting MySQL-based PHP apps to
PostgreSQL?

Cheers,

Paul




--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org

Re: Has MySQL just knowingly released a complete pile-of-shite???

--168427776-535638100-1058960621=:3838
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Paul,

thanks for your message.

On Wed, 23 Jul 2003, Paul Coldrey wrote:

> A month ago today I sent in a bug report which showed that in most
> circumstances 4.0.13 runs at 1/3 of the expected speed and blocks
> selects on tables whilst inserts are occuring (see bug 712).

IIRC, this report came in by email and was then filed into our bug
database. Thank you that you brought this to our attention!

> This was assigned low priority / non-critical status....

Yes, because it did not match the criterias for what we consider a
"critical bug":

- a security hole
- a bug that crashes mysql
- a bug that causes wrong query results

A slowdown for ALTER TABLE didn't really qualify as critical, as it's not
an operation that is frequently used. Of course, it's an issue that needed
to be addressed, and it has been fixed in the meanwhile.

> I was surprised and so I argued for a brief time that it deserved a
> higher priority and then sat patiently waiting for it to be fixed. It
> seemed odd to me that MySQL seemed completely unperturbed that there was
> such a pitifully poorly performing server released as a production
> release. Imagine my surprise when I discovered that the bug has been
> fixed but was not incorporated into 4.0.14 but instead is in the change
> list for 4.0.15.

Yes, unfortunately the release builds were almost finished by the time
this specific bug fix had been pushed into our source tree. And as there
were quite a number of other critical bug fixes that needed to be put out,
we decided to not restart the release builds once again to avoid further
delaying of the release. A full rebuild takes quite some time, as each
binary has to run through the full test suite after each build.

> I remember reading somewhere (I think on your bugs site) that all bugs
> are fixed in the next release or noted in the documentation....

Yes, this rule applies to "critical" bugs.

> I haven't checked yet, but I'm guessing the 4.0.14 documentation doesn't
> mention that MyISAM tables become pitifully slow for updates & inserts
> and block selects, if you decide to index them!

No, but we've added a note that this bug will be fixed for the 4.0.15
release.

> I have been supporter of MySQL for many years and I am now feeling very
> sad :-(.

We apologize for this. We appreciate your feedback, but this was simply an
example of bad timing.

> Is 4.0.15 expected in the next couple of days or do you expect the MySQL
> community to put up with another sub-standard release for the obligatory
> month between updates?

I would not consider this release "sub-standard" or "a complete
pile-of-shite", just because of this single missing bug fix. Therefore we
do not intend to start with 4.0.15 right away, just to include this bug
fix. Attached please find a patch that you can apply on top of the 4.0.14
source tree. Could you please give this a try and tell us, if it solves
your problems?

Sorry again if we disappointed you - it was not our intention.

Bye,
LenZ
- --
Lenz Grimmer
Senior Production Engineer
MySQL GmbH, http://www.mysql.de/
Hamburg, Germany

For technical support contracts, visit https://order.mysql.com/?ref=mlgr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)
Comment: For info see http://quantumlab.net/pine_privacy_guard/

iD8DBQE/Hne0SVDhKrJykfIRAl1oAJ473VEr/5TyyrRpet7mpnSBtouCbgCf RcHn
jxL1mF/jJtWgfKrzPP+hnbU=
=j5J3
-----END PGP SIGNATURE-----
--168427776-535638100-1058960621=:3838
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="bug_712.patch"
Content-Transfer-Encoding: BASE64
Content-ID:
Content-Description:
Content-Disposition: ATTACHMENT; FILENAME="bug_712.patch"

IyBUaGlzIGlzIGEgQml0S2VlcGVyIHBhdGNoLiAgV2hhdCBmb2xsb3dzIGFy
ZSB0aGUgdW5pZmllZCBkaWZmcyBmb3IgdGhlDQojIHNldCBvZiBkZWx0YXMg
Y29udGFpbmVkIGluIHRoZSBwYXRjaC4gIFRoZSByZXN0IG9mIHRoZSBwYXRj
aCwgdGhlIHBhcnQNCiMgdGhhdCBCaXRLZWVwZXIgY2FyZXMgYWJvdXQsIGlz
IGJlbG93IHRoZXNlIGRpZmZzLg0KIyBVc2VyOglzZXJnDQojIEhvc3Q6CXNl
cmcubXlsYW4NCiMgUm9vdDoJL3Vzci9ob21lL3NlcmcvQWJrL215c3FsLTQu
MA0KDQotLS0gMS4yMy9teWlzYW0vbWlfbG9ja2luZy5jCUZyaSBKdW4gMjgg
MTY6MjU6NTQgMjAwMg0KKysrIDEuMjUvbXlpc2FtL21pX2xvY2tpbmcuYwlT
YXQgSnVsIDE5IDE1OjE3OjI3IDIwMDMNCkBAIC0zOSw2ICszOSwxNCBAQA0K
ICAgaWYgKHNoYXJlLT5vcHRpb25zICYgSEFfT1BUSU9OX1JFQURfT05MWV9E
QVRBIHx8DQogICAgICAgaW5mby0+bG9ja190eXBlID09IGxvY2tfdHlwZSkN
CiAgICAgREJVR19SRVRVUk4oMCk7DQorICBpZiAobG9ja190eXBlID09IEZf
RVhUUkFfTENLKQ0KKyAgew0KKyAgICArK3NoYXJlLT53X2xvY2tzOw0KKyAg
ICArK3NoYXJlLT50b3RfbG9ja3M7DQorICAgIGluZm8tPmxvY2tfdHlwZT0g
bG9ja190eXBlOw0KKyAgICBEQlVHX1JFVFVSTigwKTsNCisgIH0NCisNCiAg
IGZsYWc9ZXJyb3I9MDsNCiAgIHB0aHJlYWRfbXV0ZXhfbG9jaygmc2hhcmUt
PmludGVybl9sb2NrKTsNCiAgIGlmIChzaGFyZS0+a2ZpbGUgPj0gMCkJCS8q
IE1heSBvbmx5IGJlIGZhbHNlIG9uIHdpbmRvd3MgKi8NCg0KLS0tIDEuMTAx
L215aXNhbS9teWlzYW1jaGsuYwlNb24gTWF5IDE5IDExOjAxOjM3IDIwMDMN
CisrKyAxLjEwMi9teWlzYW0vbXlpc2FtY2hrLmMJU2F0IEp1bCAxOSAxNTox
NzoyNyAyMDAzDQpAQCAtODc4LDEwICs4NzgsNyBAQA0KICAgICAgIHBhcmFt
LT5lcnJvcl9wcmludGVkPTA7DQogICAgICAgZ290byBlbmQyOw0KICAgICB9
DQotICAgIHNoYXJlLT53X2xvY2tzKys7CQkJCS8qIE1hcmsgZm9yIHdyaXRl
aW5mbyAqLw0KLSAgICBzaGFyZS0+dG90X2xvY2tzKys7DQotICAgIGluZm8t
PmxvY2tfdHlwZT0gRl9FWFRSQV9MQ0s7CQkvKiBTaW11bGF0ZSBhcyBsb2Nr
ZWQgKi8NCi0gICAgaW5mby0+dG1wX2xvY2tfdHlwZT1sb2NrX3R5cGU7DQor
ICAgIG1pX2xvY2tfZGF0YWJhc2UoaW5mbywgRl9FWFRSQV9MQ0spOw0KICAg
ICBkYXRhZmlsZT1pbmZvLT5kZmlsZTsNCiANCiAgICAgaWYgKHBhcmFtLT50
ZXN0ZmxhZyAmIChUX1JFUF9BTlkgfCBUX1NPUlRfUkVDT1JEUyB8IFRfU09S
VF9JTkRFWCkpDQpAQCAtMTA1Nyw4ICsxMDU0LDcgQEANCiAgICAgVk9JRChs
b2NrX2ZpbGUocGFyYW0sIHNoYXJlLT5rZmlsZSwwTCxGX1VOTENLLCJpbmRl
eGZpbGUiLGZpbGVuYW1lKSk7DQogICAgIGluZm8tPnVwZGF0ZSY9IH5IQV9T
VEFURV9DSEFOR0VEOw0KICAgfQ0KLSAgc2hhcmUtPndfbG9ja3MtLTsNCi0g
IHNoYXJlLT50b3RfbG9ja3MtLTsNCisgIG1pX2xvY2tfZGF0YWJhc2UoaW5m
bywgRl9VTkxDSyk7DQogZW5kMjoNCiAgIGlmIChtaV9jbG9zZShpbmZvKSkN
CiAgIHsNCg0KLS0tIDEuMTI1L3NxbC9oYV9teWlzYW0uY2MJVHVlIEp1bCAg
OCAyMjo1ODowMCAyMDAzDQorKysgMS4xMjcvc3FsL2hhX215aXNhbS5jYwlT
YXQgSnVsIDE5IDE1OjE3OjI3IDIwMDMNCkBAIC01NTksNyArNTU5LDggQEAN
CiAgIHN0cm1vdihmaXhlZF9uYW1lLGZpbGUtPmZpbGVuYW1lKTsNCiANCiAg
IC8vIERvbid0IGxvY2sgdGFibGVzIGlmIHdlIGhhdmUgdXNlZCBMT0NLIFRB
QkxFDQotICBpZiAoIXRoZC0+bG9ja2VkX3RhYmxlcyAmJiBtaV9sb2NrX2Rh
dGFiYXNlKGZpbGUsRl9XUkxDSykpDQorICBpZiAoIXRoZC0+bG9ja2VkX3Rh
YmxlcyAmJiANCisgICAgICBtaV9sb2NrX2RhdGFiYXNlKGZpbGUsIHRhYmxl
LT50bXBfdGFibGUgPyBGX0VYVFJBX0xDSyA6IEZfV1JMQ0spKQ0KICAgew0K
ICAgICBtaV9jaGVja19wcmludF9lcnJvcigmcGFyYW0sRVIoRVJfQ0FOVF9M
T0NLKSxteV9lcnJubyk7DQogICAgIERCVUdfUkVUVVJOKEhBX0FETUlOX0ZB
SUxFRCk7DQpAQCAtOTk5LDkgKzEwMDAsOSBAQA0KIA0KIGludCBoYV9teWlz
YW06OmV4dGVybmFsX2xvY2soVEhEICp0aGQsIGludCBsb2NrX3R5cGUpDQog
ew0KLSAgaWYgKCF0YWJsZS0+dG1wX3RhYmxlKQ0KLSAgICByZXR1cm4gbWlf
bG9ja19kYXRhYmFzZShmaWxlLGxvY2tfdHlwZSk7DQotICByZXR1cm4gMDsN
CisgIHJldHVybiBtaV9sb2NrX2RhdGFiYXNlKGZpbGUsICF0YWJsZS0+dG1w
X3RhYmxlID8NCisJCQkgIGxvY2tfdHlwZSA6ICgobG9ja190eXBlID09IEZf
VU5MQ0spID8NCisJCQkJICAgICAgIEZfVU5MQ0sgOiBGX0VYVFJBX0xDSykp
Ow0KIH0NCiANCiANCg==


--168427776-535638100-1058960621=:3838
Content-Type: text/plain; charset=us-ascii

--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org
--168427776-535638100-1058960621=:3838--

Re: Has MySQL just knowingly released a complete pile-of-shite???

Hi!
I just thought that I should give you my opinition on this matter.
I'm running a large web site with a heavily loaded MySQL-database behind.
There are contantly a lot of selects, inserts and updates hammering tables
with ~30 million rows. Our prodution server is currently running MySQL
3.23.57, but we are (or should I say were) just about to launch a major
update of our site. Because of the better FULLTEXT features in MySQL 4.0.x,
we were planning to upgrade the db as well. It's all been running very well
on our test server with 4.0.13, but we have not done any load testing.

I'm very glad that I got the information on this bug in 4.0.x, because it
would most probably have caused a major performance hit on our web site.
I'm NOT very glad that we will have to wait with our launch until 4.0.15 is
out...

I would most definately call this bug "critical" since it (from what I
understand from the description) seriously hits the performance on inserts
and table locking with selects. I could easily live with slower ALERT TABLE
and CREATE INDEX, but when it's affecting normal runtime performance, it's a
whole different story.
I really think you should reconsider your definition of "critical" in this
case and quickly build a new version 4.0.14a or something like that. Because
I guess it's a bit early to start asking "When will 4.0.15 be released
PLEEEASE?" :)

Just my thoughts and viewpoint
--
Tobias Lind




----- Original Message -----
From: "Lenz Grimmer"
Sent: Wednesday, July 23, 2003 1:55 PM
Subject: Re: Has MySQL just knowingly released a complete pile-of-shite???


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Paul,
>
> thanks for your message.
>
> On Wed, 23 Jul 2003, Paul Coldrey wrote:
>
> > A month ago today I sent in a bug report which showed that in most
> > circumstances 4.0.13 runs at 1/3 of the expected speed and blocks
> > selects on tables whilst inserts are occuring (see bug 712).
>
> IIRC, this report came in by email and was then filed into our bug
> database. Thank you that you brought this to our attention!
>
> > This was assigned low priority / non-critical status....
>
> Yes, because it did not match the criterias for what we consider a
> "critical bug":
>
> - a security hole
> - a bug that crashes mysql
> - a bug that causes wrong query results
>
> A slowdown for ALTER TABLE didn't really qualify as critical, as it's not
> an operation that is frequently used. Of course, it's an issue that needed
> to be addressed, and it has been fixed in the meanwhile.
>
> > I was surprised and so I argued for a brief time that it deserved a
> > higher priority and then sat patiently waiting for it to be fixed. It
> > seemed odd to me that MySQL seemed completely unperturbed that there was
> > such a pitifully poorly performing server released as a production
> > release. Imagine my surprise when I discovered that the bug has been
> > fixed but was not incorporated into 4.0.14 but instead is in the change
> > list for 4.0.15.
>
> Yes, unfortunately the release builds were almost finished by the time
> this specific bug fix had been pushed into our source tree. And as there
> were quite a number of other critical bug fixes that needed to be put out,
> we decided to not restart the release builds once again to avoid further
> delaying of the release. A full rebuild takes quite some time, as each
> binary has to run through the full test suite after each build.
>
> > I remember reading somewhere (I think on your bugs site) that all bugs
> > are fixed in the next release or noted in the documentation....
>
> Yes, this rule applies to "critical" bugs.
>
> > I haven't checked yet, but I'm guessing the 4.0.14 documentation doesn't
> > mention that MyISAM tables become pitifully slow for updates & inserts
> > and block selects, if you decide to index them!
>
> No, but we've added a note that this bug will be fixed for the 4.0.15
> release.
>
> > I have been supporter of MySQL for many years and I am now feeling very
> > sad :-(.
>
> We apologize for this. We appreciate your feedback, but this was simply an
> example of bad timing.
>
> > Is 4.0.15 expected in the next couple of days or do you expect the MySQL
> > community to put up with another sub-standard release for the obligatory
> > month between updates?
>
> I would not consider this release "sub-standard" or "a complete
> pile-of-shite", just because of this single missing bug fix. Therefore we
> do not intend to start with 4.0.15 right away, just to include this bug
> fix. Attached please find a patch that you can apply on top of the 4.0.14
> source tree. Could you please give this a try and tell us, if it solves
> your problems?
>
> Sorry again if we disappointed you - it was not our intention.
>
> Bye,
> LenZ
> - --
> Lenz Grimmer
> Senior Production Engineer
> MySQL GmbH, http://www.mysql.de/
> Hamburg, Germany
>
> For technical support contracts, visit https://order.mysql.com/?ref=mlgr
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)
> Comment: For info see http://quantumlab.net/pine_privacy_guard/
>
> iD8DBQE/Hne0SVDhKrJykfIRAl1oAJ473VEr/5TyyrRpet7mpnSBtouCbgCf RcHn
> jxL1mF/jJtWgfKrzPP+hnbU=
> =j5J3
> -----END PGP SIGNATURE-----


------------------------------------------------------------ ----------------
----


> --
> MySQL Bugs Mailing List
> For list archives: http://lists.mysql.com/bugs
> To unsubscribe: http://lists.mysql.com/bugs?unsub=tob.lind@telia.com



--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org

Re: Has MySQL just knowingly released a complete pile-of-shite???

--------------010800020700000402090300
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

The point that never seems to make it to MySQL is that it is not just
alter table - it's ALL INSERTs AND UPDATEs on any indexed MyISAM
table!!!!!!!! YES THAT'S _EVERY_ ONE! and they ALL BLOCK SELECTs. When
the bug was listed as low priority/ non-critical I updated the report
and sent personal emails Sergei Golubchik and Alexey Botchkov
explaining that it was worse than I may have led them to believe. When
this raised no response it prompted me to post a second time to the bugs
list asking others for input (and my bug got a fair few votes... it
seems other agree with me).

For my purposes (and I'm sure for many other people) it makes the
database completely worthless... people don't want to wait 12 seconds
for a menu on a web page to display because a permissions table is
blocked while a few thousand rows are inserted.

In my humble opinion, it is not a minor bug it's a show stopper! A
database that has slow, blocking inserts and updates is not a commercial
database. I started off as a true beleiver in MySQL and merrily posted a
pleasant bug report and then I discovered just how ubiquitous and
heinous the problem was I tried to raise a little visibility (still very
politely). The grumpy state you now find me in is because I waited 4
weeks for a SERIOUS bug to be fixed and I'm still waiting. And, MySQL
who I previously thought was a stalwart of quality software, is putting
out production releases that would be outperformed by Access (it's harsh
but true!).

I have spoken to most of my friends who are involved in databases and
every one of them thinks this is a critical bug. It may not be 'a
security hole', 'a bug that crashes mysql' or 'a bug that causes wrong
query results' but surely, at some point, performance has to get some
emphasis as well.

Finally, thank-you Lenz for a very polite reply given that you felt I
was off base - hopefully this email explains my exasperation and maybe
you see my position. Also, thanks Tobias for stepping into my corner...
I'm nervous about coming across as a prick but I think is serious and I
believe people would want to know about this bug. Had I known I would
never have started the major upgrade that is now going so sour.... the
lure of better full-text indexing and unions is great but not that great!

Cheers,

Paul

Tobias Lind wrote:

>Hi!
>I just thought that I should give you my opinition on this matter.
>I'm running a large web site with a heavily loaded MySQL-database behind.
>There are contantly a lot of selects, inserts and updates hammering tables
>with ~30 million rows. Our prodution server is currently running MySQL
>3.23.57, but we are (or should I say were) just about to launch a major
>update of our site. Because of the better FULLTEXT features in MySQL 4.0.x,
>we were planning to upgrade the db as well. It's all been running very well
>on our test server with 4.0.13, but we have not done any load testing.
>
>I'm very glad that I got the information on this bug in 4.0.x, because it
>would most probably have caused a major performance hit on our web site.
>I'm NOT very glad that we will have to wait with our launch until 4.0.15 is
>out...
>
>I would most definately call this bug "critical" since it (from what I
>understand from the description) seriously hits the performance on inserts
>and table locking with selects. I could easily live with slower ALERT TABLE
>and CREATE INDEX, but when it's affecting normal runtime performance, it's a
>whole different story.
>I really think you should reconsider your definition of "critical" in this
>case and quickly build a new version 4.0.14a or something like that. Because
>I guess it's a bit early to start asking "When will 4.0.15 be released
>PLEEEASE?" :)
>
>Just my thoughts and viewpoint
>--
> Tobias Lind
>
>
>
>
>----- Original Message -----
>From: "Lenz Grimmer"
>Sent: Wednesday, July 23, 2003 1:55 PM
>Subject: Re: Has MySQL just knowingly released a complete pile-of-shite???
>
>
>
>
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>Hi Paul,
>>
>>thanks for your message.
>>
>>On Wed, 23 Jul 2003, Paul Coldrey wrote:
>>
>>
>>
>>>A month ago today I sent in a bug report which showed that in most
>>>circumstances 4.0.13 runs at 1/3 of the expected speed and blocks
>>>selects on tables whilst inserts are occuring (see bug 712).
>>>
>>>
>>IIRC, this report came in by email and was then filed into our bug
>>database. Thank you that you brought this to our attention!
>>
>>
>>
>>>This was assigned low priority / non-critical status....
>>>
>>>
>>Yes, because it did not match the criterias for what we consider a
>>"critical bug":
>>
>> - a security hole
>> - a bug that crashes mysql
>> - a bug that causes wrong query results
>>
>>A slowdown for ALTER TABLE didn't really qualify as critical, as it's not
>>an operation that is frequently used. Of course, it's an issue that needed
>>to be addressed, and it has been fixed in the meanwhile.
>>
>>
>>
>>>I was surprised and so I argued for a brief time that it deserved a
>>>higher priority and then sat patiently waiting for it to be fixed. It
>>>seemed odd to me that MySQL seemed completely unperturbed that there was
>>>such a pitifully poorly performing server released as a production
>>>release. Imagine my surprise when I discovered that the bug has been
>>>fixed but was not incorporated into 4.0.14 but instead is in the change
>>>list for 4.0.15.
>>>
>>>
>>Yes, unfortunately the release builds were almost finished by the time
>>this specific bug fix had been pushed into our source tree. And as there
>>were quite a number of other critical bug fixes that needed to be put out,
>>we decided to not restart the release builds once again to avoid further
>>delaying of the release. A full rebuild takes quite some time, as each
>>binary has to run through the full test suite after each build.
>>
>>
>>
>>>I remember reading somewhere (I think on your bugs site) that all bugs
>>>are fixed in the next release or noted in the documentation....
>>>
>>>
>>Yes, this rule applies to "critical" bugs.
>>
>>
>>
>>>I haven't checked yet, but I'm guessing the 4.0.14 documentation doesn't
>>>mention that MyISAM tables become pitifully slow for updates & inserts
>>>and block selects, if you decide to index them!
>>>
>>>
>>No, but we've added a note that this bug will be fixed for the 4.0.15
>>release.
>>
>>
>>
>>>I have been supporter of MySQL for many years and I am now feeling very
>>>sad :-(.
>>>
>>>
>>We apologize for this. We appreciate your feedback, but this was simply an
>>example of bad timing.
>>
>>
>>
>>>Is 4.0.15 expected in the next couple of days or do you expect the MySQL
>>>community to put up with another sub-standard release for the obligatory
>>>month between updates?
>>>
>>>
>>I would not consider this release "sub-standard" or "a complete
>>pile-of-shite", just because of this single missing bug fix. Therefore we
>>do not intend to start with 4.0.15 right away, just to include this bug
>>fix. Attached please find a patch that you can apply on top of the 4.0.14
>>source tree. Could you please give this a try and tell us, if it solves
>>your problems?
>>
>>Sorry again if we disappointed you - it was not our intention.
>>
>>Bye,
>>LenZ
>>- --
>> Lenz Grimmer
>> Senior Production Engineer
>> MySQL GmbH, http://www.mysql.de/
>> Hamburg, Germany
>>
>> For technical support contracts, visit https://order.mysql.com/?ref=mlgr
>>-----BEGIN PGP SIGNATURE-----
>>Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)
>>Comment: For info see http://quantumlab.net/pine_privacy_guard/
>>
>>iD8DBQE/Hne0SVDhKrJykfIRAl1oAJ473VEr/5TyyrRpet7mpnSBtouCbg CfRcHn
>>jxL1mF/jJtWgfKrzPP+hnbU=
>>=j5J3
>>-----END PGP SIGNATURE-----
>>
>>
>
>
>----------------------------------------------------------- -----------------
>----
>
>
>
>
>>--
>>MySQL Bugs Mailing List
>>For list archives: http://lists.mysql.com/bugs
>>To unsubscribe: http://lists.mysql.com/bugs?unsub=tob.lind@telia.com
>>
>>
>
>
>
>
>


--------------010800020700000402090300--

Re: Has MySQL just knowingly released a complete pile-of-shite???

Hi!

On Jul 23, Tobias Lind wrote:
> Hi!
> I just thought that I should give you my opinition on this matter.
>
> I'm very glad that I got the information on this bug in 4.0.x, because it
> would most probably have caused a major performance hit on our web site.
> I'm NOT very glad that we will have to wait with our launch until 4.0.15 is
> out...
>
> I would most definately call this bug "critical" since it (from what I
> understand from the description) seriously hits the performance on inserts
> and table locking with selects. I could easily live with slower ALERT TABLE
> and CREATE INDEX, but when it's affecting normal runtime performance, it's a
> whole different story.

You see, what was fixed, should most porbably affect only ALTER TABLE
and related commands - exactly as I wrote in manual's changelog.

We were not able to repeat "slow normal runtime performance" - in all
the tests we did normal and concurrenrt perfomance was not affected.

ALTER TABLE slowdown was real and repeatable - and it was fixed.
But as ALTER TABLE is not very fast command on itself (we planning to
make it faster - it does lots of unnecessary work sometimes) and it's
not very used, we decided to let other - critical - bugfixes out,
instead of forcing the users to wait for this - relatively harmless
(compared to others) - problem.

> I really think you should reconsider your definition of "critical" in this
> case and quickly build a new version 4.0.14a or something like that. Because

Hopefully, I was able to clarify our definition of "critical".

> I guess it's a bit early to start asking "When will 4.0.15 be released
> PLEEEASE?" :)

:)
No fixed dates yet (of course), but still we want even "non-critical"
bugs to be fixed asap, so you will not wait for 4.0.15 too long.

> Just my thoughts and viewpoint

Yes, sure. Thank you. And don't hesitate to do it again -
we appreciate it a lot

Regards,
Sergei

--
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Sergei Golubchik
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Senior Software Developer
/_/ /_/\_, /___/\___\_\___/ Osnabrueck, Germany
<___/ www.mysql.com

--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org

Re: Has MySQL just knowingly released a complete pile-of-shite???

On Wed, Jul 23, 2003 at 11:15:00PM +0930, Paul Coldrey wrote:
> The point that never seems to make it to MySQL is that it is not just
> alter table - it's ALL INSERTs AND UPDATEs on any indexed MyISAM
> table!!!!!!!! YES THAT'S _EVERY_ ONE! and they ALL BLOCK SELECTs. When
> the bug was listed as low priority/ non-critical I updated the report
> and sent personal emails Sergei Golubchik and Alexey Botchkov
> explaining that it was worse than I may have led them to believe. When
> this raised no response it prompted me to post a second time to the bugs
> list asking others for input (and my bug got a fair few votes... it
> seems other agree with me).
>
> For my purposes (and I'm sure for many other people) it makes the
> database completely worthless... people don't want to wait 12 seconds
> for a menu on a web page to display because a permissions table is
> blocked while a few thousand rows are inserted.
>
> In my humble opinion, it is not a minor bug it's a show stopper!

It's also very likely to be specific to something in your setup.

I just checked our stats and found roughly 220 installed copies of
various 4.0.13 versions without anyone reporting massive performance
problems like you've described.

I'm not saying that the problem doesn't exist, but there's a chance
it's not affecting quite as many people as you think too...

Jeremy
--
Jeremy D. Zawodny | Perl, Web, MySQL, Linux Magazine, Yahoo!
| http://jeremy.zawodny.com/

--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org

Re: Has MySQL just knowingly released a complete pile-of-shite???

Just to add my 2 cents to this discussion.....

I have been racking my brain lately trying to figure out why the load
on my
database server has gone up so much since upgrading to the 4.0.12
release from 3.23.
I didn't notice it right after the upgrade, but over time it has become
a real issue.
The load average on my server has been around 2.5 at slow times and
jumps
to around 8 or so during heavy use. This is a 4 processor machine with
8GB of
RAM. We have been writing quite a few new applications and we have been
trying to find out what was causing so many slow queries. Our
assumption was bad code
on our end.

After seeing this, I applied the patch to the 4.0.14 release and
compiled it and
now everything is running wonderfully. Load average is back down to
about 0.5
and 2.0 under heavy use. Queries are lightning fast again.

I know people might say it was something else (compiler, libraries,
whatever) but
I know it works now and in my opinion it didn't before.

By the way, I have been using MySQL for 3 years now and I would never
consider
running anything else. I love the product, it is one of the few things
that I never
have to worry about, it always just works. But this is more than a
minor bug
in my opinion. If i am reading this right, this has the most effect on
heavily loaded
servers. We were very excited to see 4.0 become production because of
replication.
I think a lot of the users who fall into this category were waiting to
upgrade to 4.0 because
of replication and improved searching. It is just discouraging when
you move 1 step
forward but 2 back.

I think this should have been given a higher priority than it did,
especially in a
production release.

Thank you for the great product.

Cory Patterson


On Wednesday, July 23, 2003, at 02:55 PM, Jeremy Zawodny wrote:

> On Wed, Jul 23, 2003 at 11:15:00PM +0930, Paul Coldrey wrote:
>> The point that never seems to make it to MySQL is that it is not just
>> alter table - it's ALL INSERTs AND UPDATEs on any indexed MyISAM
>> table!!!!!!!! YES THAT'S _EVERY_ ONE! and they ALL BLOCK SELECTs.
>> When
>> the bug was listed as low priority/ non-critical I updated the report
>> and sent personal emails Sergei Golubchik and Alexey Botchkov
>> explaining that it was worse than I may have led them to believe. When
>> this raised no response it prompted me to post a second time to the
>> bugs
>> list asking others for input (and my bug got a fair few votes... it
>> seems other agree with me).
>>
>> For my purposes (and I'm sure for many other people) it makes the
>> database completely worthless... people don't want to wait 12 seconds
>> for a menu on a web page to display because a permissions table is
>> blocked while a few thousand rows are inserted.
>>
>> In my humble opinion, it is not a minor bug it's a show stopper!
>
> It's also very likely to be specific to something in your setup.
>
> I just checked our stats and found roughly 220 installed copies of
> various 4.0.13 versions without anyone reporting massive performance
> problems like you've described.
>
> I'm not saying that the problem doesn't exist, but there's a chance
> it's not affecting quite as many people as you think too...
>
> Jeremy
> --
> Jeremy D. Zawodny | Perl, Web, MySQL, Linux Magazine, Yahoo!
> | http://jeremy.zawodny.com/
>
> --
> MySQL Bugs Mailing List
> For list archives: http://lists.mysql.com/bugs
> To unsubscribe: http://lists.mysql.com/bugs?unsub=pattejam@z1g.com


--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org

Re: Has MySQL just knowingly released a complete pile-of-shite???

Hi Cory,

Thanks for your feedback, much of my frustration stems from the fact
that the guys at MySQL did not respond when I alerted them to more
issues relating the indexed MyISAM tables. I did not realise, until this
morning, that there was any problem with repeating the bug. Had I known
I would have put together a proper test case a month ago.

On that note, in trying to fabricate a simple test case for you it
appears I was wrong about how prevalent the bug is - I was assuming the
create index and update/insert/select-on-indexed-tables bugs were
related and hence very easy to repeat. Unfortunately I'm busy with other
things today but I will hopefully get a chance to put together a test
case that exposes the bug this evening.

Cheers,

Paul.

Cory Patterson wrote:

> Just to add my 2 cents to this discussion.....
>
> I have been racking my brain lately trying to figure out why the load
> on my
> database server has gone up so much since upgrading to the 4.0.12
> release from 3.23.
> I didn't notice it right after the upgrade, but over time it has
> become a real issue.
> The load average on my server has been around 2.5 at slow times and jumps
> to around 8 or so during heavy use. This is a 4 processor machine
> with 8GB of
> RAM. We have been writing quite a few new applications and we have been
> trying to find out what was causing so many slow queries. Our
> assumption was bad code
> on our end.
>
> After seeing this, I applied the patch to the 4.0.14 release and
> compiled it and
> now everything is running wonderfully. Load average is back down to
> about 0.5
> and 2.0 under heavy use. Queries are lightning fast again.
>
> I know people might say it was something else (compiler, libraries,
> whatever) but
> I know it works now and in my opinion it didn't before.
>
> By the way, I have been using MySQL for 3 years now and I would never
> consider
> running anything else. I love the product, it is one of the few
> things that I never
> have to worry about, it always just works. But this is more than a
> minor bug
> in my opinion. If i am reading this right, this has the most effect
> on heavily loaded
> servers. We were very excited to see 4.0 become production because of
> replication.
> I think a lot of the users who fall into this category were waiting to
> upgrade to 4.0 because
> of replication and improved searching. It is just discouraging when
> you move 1 step
> forward but 2 back.
>
> I think this should have been given a higher priority than it did,
> especially in a
> production release.
>
> Thank you for the great product.
>
> Cory Patterson
>
>
> On Wednesday, July 23, 2003, at 02:55 PM, Jeremy Zawodny wrote:
>
>> On Wed, Jul 23, 2003 at 11:15:00PM +0930, Paul Coldrey wrote:
>>
>>> The point that never seems to make it to MySQL is that it is not just
>>> alter table - it's ALL INSERTs AND UPDATEs on any indexed MyISAM
>>> table!!!!!!!! YES THAT'S _EVERY_ ONE! and they ALL BLOCK SELECTs. When
>>> the bug was listed as low priority/ non-critical I updated the report
>>> and sent personal emails Sergei Golubchik and Alexey Botchkov
>>> explaining that it was worse than I may have led them to believe. When
>>> this raised no response it prompted me to post a second time to the
>>> bugs
>>> list asking others for input (and my bug got a fair few votes... it
>>> seems other agree with me).
>>>
>>> For my purposes (and I'm sure for many other people) it makes the
>>> database completely worthless... people don't want to wait 12 seconds
>>> for a menu on a web page to display because a permissions table is
>>> blocked while a few thousand rows are inserted.
>>>
>>> In my humble opinion, it is not a minor bug it's a show stopper!
>>
>>
>> It's also very likely to be specific to something in your setup.
>>
>> I just checked our stats and found roughly 220 installed copies of
>> various 4.0.13 versions without anyone reporting massive performance
>> problems like you've described.
>>
>> I'm not saying that the problem doesn't exist, but there's a chance
>> it's not affecting quite as many people as you think too...
>>
>> Jeremy
>> --
>> Jeremy D. Zawodny | Perl, Web, MySQL, Linux Magazine, Yahoo!
>> | http://jeremy.zawodny.com/
>>
>> --
>> MySQL Bugs Mailing List
>> For list archives: http://lists.mysql.com/bugs
>> To unsubscribe: http://lists.mysql.com/bugs?unsub=pattejam@z1g.com
>
>
>



--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org

RE: Has MySQL just knowingly released a complete pile-of-shite???

What patches did you apply? A friend and I have been debating this
issue and are trying to find which patches were applied and we've come
up with two possiblities (none were listed on bugs.mysql.com, that one
does not refer back to the original bug)

http://mysql.bkbits.net:8080/mysql-4.0/patch@1.1516.2.1?nav= index.html|C
hangeSet@-3w|cset@1.1516.2.1
http://mysql.bkbits.net:8080/mysql-4.0/patch@1.1535?nav=inde x.html|Chang
eSet@-3w|cset@1.1535

Has anyone else been able to reproduce this being problematic with
regular queries beyond ALTER? I can understand there are some people
that are running 4.0.x and say it runs fine, but if they have been
running the same 4.0.x source that is less efficient they may not know
any different, whereas someone that's using a fast version and then goes
a slow version will easily see the problems. I may get the guts to
upgrade my server to 4.0.14 and see how things go, if so I will report
back. Although I am very hesitant when my two separate servers do 700
queries/sec (9.4 read/write) and 1800 queries/sec (12.6 read/write)

Nickg


-----Original Message-----
From: Cory Patterson [mailto:pattejam@z1g.com]
Sent: Wednesday, July 23, 2003 2:51 PM
To: bugs@lists.mysql.com
Subject: Re: Has MySQL just knowingly released a complete
pile-of-shite???


Just to add my 2 cents to this discussion.....

I have been racking my brain lately trying to figure out why the load
on my
database server has gone up so much since upgrading to the 4.0.12
release from 3.23.
I didn't notice it right after the upgrade, but over time it has become
a real issue.
The load average on my server has been around 2.5 at slow times and
jumps
to around 8 or so during heavy use. This is a 4 processor machine with
8GB of
RAM. We have been writing quite a few new applications and we have been
trying to find out what was causing so many slow queries. Our
assumption was bad code
on our end.

After seeing this, I applied the patch to the 4.0.14 release and
compiled it and
now everything is running wonderfully. Load average is back down to
about 0.5
and 2.0 under heavy use. Queries are lightning fast again.

I know people might say it was something else (compiler, libraries,
whatever) but
I know it works now and in my opinion it didn't before.

By the way, I have been using MySQL for 3 years now and I would never
consider
running anything else. I love the product, it is one of the few things
that I never
have to worry about, it always just works. But this is more than a
minor bug
in my opinion. If i am reading this right, this has the most effect on
heavily loaded
servers. We were very excited to see 4.0 become production because of
replication.
I think a lot of the users who fall into this category were waiting to
upgrade to 4.0 because
of replication and improved searching. It is just discouraging when
you move 1 step
forward but 2 back.

I think this should have been given a higher priority than it did,
especially in a
production release.

Thank you for the great product.

Cory Patterson

--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe:
http://lists.mysql.com/bugs?unsub=mysqlbug@ngworld.net


--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org

Re: Has MySQL just knowingly released a complete pile-of-shite???

Hi

> I just checked our stats and found roughly 220 installed copies of
> various 4.0.13 versions without anyone reporting massive performance
> problems like you've described.
Well, acually I found a problem which I am able to repeat, but don't acually
know if it is a mysql bug or expected behaviour. I will explain it below and
I may send you a db dump if you want a repeatable testcase.

The origin of my problem was an error in my sql query, it was:
### QUERY START ###
SELECT DISTINCT ezsearch_object_word_link.contentobject_id,
ezsearch_object_word_link.published
FROM
ezcontentobject,
ezsearch_object_word_link
,
ezcontentclass,
ezcontentobject_tree
WHERE
( ezsearch_object_word_link.word_id='172060' AND
ezsearch_object_word_link.next_word_id='170990' ) OR (
ezsearch_object_word_link.word_id='170990' AND
ezsearch_object_word_link.prev_word_id='172060' ) AND
ezcontentobject.id=ezsearch_object_word_link.contentobject_i d
and
ezcontentobject.contentclass_id = ezcontentclass.id and
ezcontentclass.version = '0' and
ezcontentobject.id = ezcontentobject_tree.contentobject_id
and
ezcontentobject_tree.node_id =
ezcontentobject_tree.main_node_id;

### QUERY STOP ###

But it should be (lacks two paranthesis in the WHERE clause)
### QUERY START ###
SELECT DISTINCT ezsearch_object_word_link.contentobject_id,
ezsearch_object_word_link.published
FROM
ezcontentobject,
ezsearch_object_word_link
,
ezcontentclass,
ezcontentobject_tree
WHERE
( ( ezsearch_object_word_link.word_id='172060' AND
ezsearch_object_word_link.next_word_id='170990' ) OR (
ezsearch_object_word_link.word_id='170990' AND
ezsearch_object_word_link.prev_word_id='172060' ) ) AND
ezcontentobject.id=ezsearch_object_word_link.contentobject_i d
and
ezcontentobject.contentclass_id = ezcontentclass.id and
ezcontentclass.version = '0' and
ezcontentobject.id = ezcontentobject_tree.contentobject_id
and
ezcontentobject_tree.node_id =
ezcontentobject_tree.main_node_id;
### QUERY STOP ###

My faulty query causes the mysqlthread performing the query to run
(apparently) forever, which is acually probably OK (since there are f*** many
rows in question)

However, while this query runs, any write queries to ezcontentobject is
blocked, is that correct behaviour ?
or is this a symptom of the BLOCK issues you are talking about ?
It is kinda wierd that tables may be blocked by SELECT queries ? It will
certainly impact performance.

mysql> show full processlist;
| 50 | vtest | localhost | bug1 | Query | 37 | Copying to tmp
table | SELECT DISTINCT ezsearch_object_word_link(.........)
| 51 | vtest | localhost | bug1 | Query | 3 | Locked
| update ezcontentobject set status=2 where id=1


I tested with 4.0.13 (linux rh9, rpm binaries from mysql)

Best regards,
Vidar


On Wednesday 23 July 2003 20:55, Jeremy Zawodny wrote:
> On Wed, Jul 23, 2003 at 11:15:00PM +0930, Paul Coldrey wrote:
> > The point that never seems to make it to MySQL is that it is not just
> > alter table - it's ALL INSERTs AND UPDATEs on any indexed MyISAM
> > table!!!!!!!! YES THAT'S _EVERY_ ONE! and they ALL BLOCK SELECTs. When
> > the bug was listed as low priority/ non-critical I updated the report
> > and sent personal emails Sergei Golubchik and Alexey Botchkov
> > explaining that it was worse than I may have led them to believe. When
> > this raised no response it prompted me to post a second time to the bugs
> > list asking others for input (and my bug got a fair few votes... it
> > seems other agree with me).
> >
> > For my purposes (and I'm sure for many other people) it makes the
> > database completely worthless... people don't want to wait 12 seconds
> > for a menu on a web page to display because a permissions table is
> > blocked while a few thousand rows are inserted.
> >
> > In my humble opinion, it is not a minor bug it's a show stopper!
>
> It's also very likely to be specific to something in your setup.
>
> I just checked our stats and found roughly 220 installed copies of
> various 4.0.13 versions without anyone reporting massive performance
> problems like you've described.
>
> I'm not saying that the problem doesn't exist, but there's a chance
> it's not affecting quite as many people as you think too...
>
> Jeremy
> --
> Jeremy D. Zawodny | Perl, Web, MySQL, Linux Magazine, Yahoo!
> | http://jeremy.zawodny.com/

--
vidar



--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org

Re: Has MySQL just knowingly released a complete pile-of-shite???

--Apple-Mail-5--856424083
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
format=flowed

Hello,

I was also very hesitant to upgrade because our server has a high rate
of sustained queries.
Unfortunately, I cannot give you any info to repeat the bug. It is
more just seeing the server
run much faster and run at a lot lower load average under the same load
as before the patch.

I had to apply the patch by hand to the 4.0.14 source, but i have
attached a diff that should work for you.

Cory


--Apple-Mail-5--856424083
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
delsp=yes;
charset=US-ASCII;
format=flowed






On Thursday, July 24, 2003, at 02:19 AM, Nick Gaugler wrote:

> What patches did you apply? A friend and I have been debating this
> issue and are trying to find which patches were applied and we've come
> up with two possiblities (none were listed on bugs.mysql.com, that one
> does not refer back to the original bug)
>
> http://mysql.bkbits.net:8080/mysql-4.0/
> patch@1.1516.2.1?nav=index.html|C
> hangeSet@-3w|cset@1.1516.2.1
> http://mysql.bkbits.net:8080/mysql-4.0/
> patch@1.1535?nav=index.html|Chang
> eSet@-3w|cset@1.1535
>
> Has anyone else been able to reproduce this being problematic with
> regular queries beyond ALTER? I can understand there are some people
> that are running 4.0.x and say it runs fine, but if they have been
> running the same 4.0.x source that is less efficient they may not know
> any different, whereas someone that's using a fast version and then
> goes
> a slow version will easily see the problems. I may get the guts to
> upgrade my server to 4.0.14 and see how things go, if so I will report
> back. Although I am very hesitant when my two separate servers do 700
> queries/sec (9.4 read/write) and 1800 queries/sec (12.6 read/write)
>
> Nickg
>
>
> -----Original Message-----
> From: Cory Patterson [mailto:pattejam@z1g.com]
> Sent: Wednesday, July 23, 2003 2:51 PM
> To: bugs@lists.mysql.com
> Subject: Re: Has MySQL just knowingly released a complete
> pile-of-shite???
>
>
> Just to add my 2 cents to this discussion.....
>
> I have been racking my brain lately trying to figure out why the load
> on my
> database server has gone up so much since upgrading to the 4.0.12
> release from 3.23.
> I didn't notice it right after the upgrade, but over time it has become
> a real issue.
> The load average on my server has been around 2.5 at slow times and
> jumps
> to around 8 or so during heavy use. This is a 4 processor machine with
> 8GB of
> RAM. We have been writing quite a few new applications and we have
> been
> trying to find out what was causing so many slow queries. Our
> assumption was bad code
> on our end.
>
> After seeing this, I applied the patch to the 4.0.14 release and
> compiled it and
> now everything is running wonderfully. Load average is back down to
> about 0.5
> and 2.0 under heavy use. Queries are lightning fast again.
>
> I know people might say it was something else (compiler, libraries,
> whatever) but
> I know it works now and in my opinion it didn't before.
>
> By the way, I have been using MySQL for 3 years now and I would never
> consider
> running anything else. I love the product, it is one of the few things
> that I never
> have to worry about, it always just works. But this is more than a
> minor bug
> in my opinion. If i am reading this right, this has the most effect on
> heavily loaded
> servers. We were very excited to see 4.0 become production because of
> replication.
> I think a lot of the users who fall into this category were waiting to
> upgrade to 4.0 because
> of replication and improved searching. It is just discouraging when
> you move 1 step
> forward but 2 back.
>
> I think this should have been given a higher priority than it did,
> especially in a
> production release.
>
> Thank you for the great product.
>
> Cory Patterson
>
> --
> MySQL Bugs Mailing List
> For list archives: http://lists.mysql.com/bugs
> To unsubscribe:
> http://lists.mysql.com/bugs?unsub=mysqlbug@ngworld.net


--Apple-Mail-5--856424083
Content-Type: text/plain; charset=us-ascii

--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org
--Apple-Mail-5--856424083--

Re: Has MySQL just knowingly released a complete pile-of-shite???

Hi!

On Jul 24, Vidar wrote:
>
> Hi
>
> > I just checked our stats and found roughly 220 installed copies of
> > various 4.0.13 versions without anyone reporting massive performance
> > problems like you've described.
> Well, acually I found a problem which I am able to repeat, but don't acually
> know if it is a mysql bug or expected behaviour.
....
> However, while this query runs, any write queries to ezcontentobject is
> blocked, is that correct behaviour ?
> or is this a symptom of the BLOCK issues you are talking about ?
> It is kinda wierd that tables may be blocked by SELECT queries ? It will
> certainly impact performance.

Yes, it's normal.
MyISAM tables support only table-level locking. Thus, if a thread is
modifying a table, no other thread can access this table. Also, a thread
cannot start to update the table if there's ongoing read (SELECT)
operation on it.

Of course, multiple reads can be performed concurrently.
INSERT can be done concurrently with SELECTs, only if the MYD file has
no holes - usually it means that no data were deleted from the last
OPTIMIZE.

For full read-write concurrency you have to use InnoDB tables.

Regards,
Sergei

--
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Sergei Golubchik
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Senior Software Developer
/_/ /_/\_, /___/\___\_\___/ Osnabrueck, Germany
<___/ www.mysql.com

--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org