The errata list is a list of errors and their corrections that were found after the product was released.
The following errata were submitted by our customers and have not yet been approved or disproved by the author or editor. They solely represent the opinion of the customer.
| Version |
Location |
Description |
Submitted by |
Date submitted |
|
chapter 1.4.
chapter 1.4., first enumeration, first item |
"InnoDB must find a version of the row that is at least as old as the transaction"
should be
"InnoDB must find the youngest version of the row that is at least as old as the transaction"
note on the errata submission form: Safari Books readers cannot determine page numbers
|
Anonymous |
Nov 26, 2008 |
|
8
READ COMMITTED explanation |
The explanation of READ COMMITTED says:
"It satisfies the simple definition of isolation used earlier: a transaction will see only those changes made by transactions that were already committed when it began..."
This is not quite true -- the transaction will see any committed transactions, even those that commit while the transaction in question is running.
Example:
Assume table_a has one row with column_a = 1.
A: begin
B: begin
B: UPDATE table_a SET column_a = 100;
B: commit
A: SELECT * FROM table_a
The row returned will have column_a = 100, even though column_a = 1 at the time the transaction began. Transaction B committed after transaction A began, yet transaction A sees transaction B's changes. This doesn't match the description given above.
|
Andrew Miklas |
Jun 03, 2011 |
| Printed |
Page 48
first code snippet |
"The following command runs the random read/write access file I/O benchmark:
$ sysbench --test=fileio --file-total-size=150G --file-test-mode=rndwr --init-rnd=on --max-time=300 --max-requests=0 run"
The --init-rnd option is not recognized by sysbench v0.4.8 on FC7, compiled from source.
It should be "--init-rng=on" instead.
|
Anonymous |
|
| Printed |
Page 69
last paragraph (6) |
"represented as base-64 by default"
should be:
"represented as base-16 by default"
|
Anonymous |
|
| Printed |
Page 116
Figure 3-8 |
This is request for clarification:
You mention that indexes, including secondary ones, are always sorted based on the key. In this example, you have 10K entries and col2 ranges between 0-100, randomly chosen. The secondary index (here for InnoDB) on col2 will have many similar values (avg: 10K/100). So, for the leaf nodes, when the secondary index is similar, will the 'pointers' ie primary key values be used for sorting? However, in your fig 3-8, this is how you show -- see 8->18 followed by 8->99. Would also like to know that if primary key is participating in sort, is that by design or based on implementation -- if latter, then I will be skeptical since there's no gurantee of similar implementation in future releases.
Please clarify these. Thanks for the good book, BTW.
|
Anonymous |
Sep 21, 2009 |
| Printed |
Page 140
Last paragraph |
The description of the subsequent query is incorrect. It says "... view the last 10 messages from each of the premium users." Since there's no "group by" in the query, it will actually return the last 10 messages by any premium user. In other words, if there are 5 premium users, the query returns up to 10 records, not up to 50 records.
|
Anonymous |
|
| Printed |
Page 179
4th paragraph |
Replace "....by finding a list of actor_id values and substituting them..."
with:
"....by finding a list of film_id values and substituting them..."
|
Anonymous |
Jan 02, 2009 |
| Printed |
Page 211
Host matching, 3rd list |
I think this list was sorted by wrong order.
this book says:
@joe.example.com
@%.example.com
jane@%.example.com
jane@%
I think:
@joe.example.com
jane@%.example.com
@%.example.com
jane@%
|
Anonymous |
|
| Printed |
Page 339
Last paragraph before A CPU-Bound Machine section |
The first sentence of that paragraph says the concurrency formula shows the device is handling just one request per second. I think it should actually say that it is handling "just one concurrent request".
|
Robert Stewart |
Oct 04, 2010 |
| Printed |
Page 354
5th paragraph |
Written as:
innodb_flush_logs_at_trx_commit=1
should be (without the s in logs):
innodb_flush_log_at_trx_commit=1
|
Greg Lindholm |
Jul 07, 2009 |
| Printed |
Page 386
code |
The statement to change master of server 3 to server 2 :
should be
server3> CHANGE MASTER TO MASTER_HOST="server2"...
not
server2> CHANGE MASTER TO MASTER_HOST="server2"...
|
Anonymous |
Aug 19, 2011 |