Getting excited. October 5th to October 8th. 3 days of SQL training. 4 hour sessions each day with 4 hours of one on one help.
Oh I'm doing all the training. Very excited. I think I over prepared I have like 20hours of material I put together.
I'm late to the party. But I built my first power bi dashboard to be able to elegantly present some data for better software development priorities in database pipelines.
Well this is terrifying
The scariest number here: 3.61% of CPUs in one large-scale study were found to cause silent data corruptions. Not “a few bad chips.” Nearly 4 out of every 100 processors doing math wrong, silently, with no error log.
Google coined the term “mercurial cores” in 2021 after their production teams kept blaming software for data corruption. They’d debug for weeks, find nothing wrong with the code, swap the machine, problem gone. The actual cause: manufacturing defects at sub-7nm that pass every factory test, then degrade unpredictably months or years after deployment.
Facebook confirmed the same thing independently. Hundreds of affected CPUs across hundreds of thousands of machines. The defect doesn’t crash your system. It just gives you 5 instead of 6 when you multiply 2x3, under specific microarchitectural conditions, with zero indication anything went wrong.
Now think about what this means for AI training. A single corrupted GPU or CPU in a distributed training cluster doesn’t just produce one bad output. It feeds corrupted gradients into a synchronization step that gets averaged across every accelerator in the cluster. One bad chip can silently poison an entire training run. NVIDIA published a whitepaper on exactly this problem. Loss spikes during LLM training that nobody could explain traced back to silent hardware corruption.
The part that keeps infrastructure engineers up at night: traditional defenses don’t work. ECC memory can’t catch this because the corruption happens during computation, not storage. Checksums like CRC heavily use vector operations, which are themselves one of the most vulnerable instruction types. The tools designed to detect corruption are running on the same flawed silicon.
Google’s current detection method? Roughly half human-driven, half automated. And of the machines humans flag as suspicious, only about 50% are actually confirmed mercurial on deeper investigation. We’re debugging trillion-parameter models on hardware where we can’t reliably tell which chips are lying to us.
Moore’s Law gave us more transistors. It also gave us transistors we can’t fully verify.
Readers added context they thought people might want to know
The actual number is 3.61‱ (using the per-ten-thousand symbol ‱, also known as "permyriad").
This equates to 3.61 per 10,000 CPUs (or 0.0361%).
x.com/i/status/20226…
Going to be taking more active effort in life. What books help a reflective and meaningful life to you? Taking recommendations.
Starting with Born a Crime by Trevor Noah.
And Guns Germs And Steel. By Jared Diamond
Prayers for the Philippines. Even though Kristine wasn't super powerful. She just sat on us for over 24hrs. Areas which have never flood, are chest deep with water.
Power and many public services are out.
Daniel Maenle retweeted
Hello, Detroit! With only two weeks left until Election Day, we’ve got to do all we can to elect Kamala Harris and Tim Walz. Tune in to hear from me and Eminem: xitter.cf/i/broadcasts/1LyGBgjBj…
To all my #sqlfamily
I wish you a great day. As a person living in the future(8pm Thursday for me)(well for those in the USA and Canada anyway) I can share that Thursday was great. And I wish you to enjoy it.
When reviewing trending topics I saw "moron" I reviewed and saw what I expected. People on each USA political side calling each other morons. Accidentally clicked from top to people. Saw this. @elonmusk got trolled on his own platform.
Daniel Maenle retweeted
To explain this a bit more to those who have asked:
The documentation for CAST & CONVERT says:
Starting with SQL Server 2012 (11.x), when using supplementary character (SC) collations, a CAST operation from nchar or nvarchar to an nchar or nvarchar type of smaller length won't truncate inside a surrogate pair. Instead, the operation truncates before the supplementary character.
Under an SC collation, each character has a variable byte length. For example, N'X' takes 2 bytes, while N'😎' uses 4 bytes.
The string N'X😎' (both characters together) requires 2 + 4 = 6 bytes of storage, corresponding to nvarchar(3). The number in brackets is the number of byte-pairs, not the number of characters. Three byte-pairs = 2 * 3 = 6 bytes. Yes, it's confusing but that's how it is.
-- Returns 6 (bytes) and 2 (characters)
DECLARE @y nvarchar(3) = N'X😎';
SELECT DATALENGTH(@y), LEN(@y);
If we convert the string to a smaller type, truncation occurs:
-- Returns "X", 2 (bytes), and 1 (character)
DECLARE @y nvarchar(3) = N'X😎';
SELECT
CONVERT(nvarchar(2), @y),
DATALENGTH(CONVERT(nvarchar(2), @y)),
LEN(CONVERT(nvarchar(2), @y));
This is the correct behaviour. Truncation stores as many whole characters from the string as will fit in the destination type. nvarchar(2) offers 2 * 2 = 4 bytes, which is only enough to store the first character, N'X'. There is not enough space left to store the 4 bytes of N'😎'.
The bug occurs when the source is a LOB type, the destination is nvarchar (or nchar), truncation is needed, and the truncation point occurs within a (variable length) character.
Using the same example with a LOB source:
-- Returns "X�", 4 (bytes), and 2 (characters)
DECLARE @y nvarchar(max) = N'X😎';
SELECT
CONVERT(nvarchar(2), @y),
DATALENGTH(CONVERT(nvarchar(2), @y)),
LEN(CONVERT(nvarchar(2), @y));
The funny-looking second character is the first 2 bytes of N'😎' (which requires 4 bytes). Conversion has split this character in half! This is the bug.
an interesting bug report from @SQL_Kiwi - feedback.azure.com/d365commu…
Enjoying Amsterdam for my first time and have to pay my homage to an excellent author and inspiration to so many in life. @sportswithjohn , #tfios ,#dftba















