evanelias

The burst of the dotcom bubble, in terms of market peak to trough, took two and a half years before the bottom was hit.

No, GP is correct. In the pilot, the ship was in the process of being decommissioned from military use and converted to a museum. It wasn't already a museum prior to the events in the pilot (if that's what you meant -- maybe I'm not really sure what your comment was saying.)

Ehh, maybe that notion times ten. These recent episodes are far goofier and more nonsensical than that TNG episode. (and again, my view on them is far less harsh than many of the reviews I've seen online...)

At least the TNG duds attempted some kind of sci fi technobabble explanation for whatever hijinks were occurring. With this season of SNW, we're getting plot devices like "missing resistance leader just happened to look identical to Enterprise's first officer by complete coincidence!" and "spooky derelict ship is haunted, no explanation even attempted!" ... there are worse ones I could reference but they're spoilers. I'm genuinely starting to wonder if an LLM is writing these scripts.

re: taking it seriously, I meant more in terms of whether it is "good art" vs disposable entertainment. On the whole, I felt that TNG and DS9 both eventually found the right balance of drama and humor, often with an intelligent underlying message about aspects of our society and culture. The modern Star Trek shows are sorely lacking in that area!

The difference is the sheer number of gimmick episodes: so far half the episodes this season fall into that category. Did you actually watch that puppet episode you're quoting? Gimmick aside, it had one of the dumbest endings of any Star Trek episode I can think of.

In this specific case (Tailwind Labs) I don't understand this sentiment at all. It was a completely bootstrapped company! Its entire existence is due to the many years of difficult work by its founders.

What exact outcome would correctly align with "good leadership" in your view? It sounds like you think the CEO/cofounder should have "gone down with the ship" here -- how does that help anyone if it means the entire company would have failed?

Interesting, I wouldn't have expected that auto_increment replication problem to occur for InnoDB tables that have a clustered index key (the old PK converted to UNIQUE), that is indeed surprising. Maybe the SQL layer does something dumb here and thinks the table doesn't have a defined ordering because it has no explicit PK -- even though internally in the storage engine it would still have the table organized by the old PK if it was a UNIQUE KEY over non-NULLable columns.

But even that aside, I still say the binlog_format is irrelevant and the core problem here is 100% the ALTER to add the auto_increment: it resulted in different IDs on the replica than on the primary. That's a problem if you refer to IDs externally anywhere, regardless of whether it's 6 child tables or an external cache or logging etc. As soon as you promote a replica for any reason (not just an upgrade, any failover reason whatsoever) this would be a massive problem as all the IDs would now refer to different rows. And even before a failover event, if you do any reads from the replica for any purpose (read scaling, backups, OLAP queries), the data is going to be wrong.

Essentially for the 6 child tables, it wouldn't have mattered if their UPDATEs had all used ROW or all used STATEMENT; either way you would have still had a fundamental data inconsistency between primary and replica here for the parent table. If these 6 tables' UPDATEs all used ROW, they would refer to the IDs from the primary which are locally "wrong" on the replica. Or if they all used STATEMENT then the data on the replica would be consistent locally but completely different than what's on the primary.

Huh, if the table effectively already had a clustered index key (from the old PK) then I'm surprised that the auto_inc values would be assigned non-deterministically. I would have naively assumed that the values would be assigned in clustered index key order. Maybe this is one of those cases where too much logic is handled outside the storage engine?

Anyway yes nice to see you here too Fernando! Good call on the noop pt-osc, I always forget about all the cool tricks that tool can do when applied in non-obvious ways.

No, the binlog format is actually irrelevant here; the post author was just incorrect about that part. ALTER TABLE always gets replicated as a statement, regardless of the binlog format.

Auto_increment only has broken replication semantics in the very specific situation the author encountered: a table has data, but no primary key (and also no alternative unique index which could serve as the clustered index key) and then an attempt is made to alter the table to add an auto_increment primary key.

Basically that form of ALTER TABLE statement is telling the database to add a sequential ID to each existing row, but without providing any deterministic way that those numbers should be assigned. So each replica may choose a different numbering, causing the problem experienced by the author.

It's a foot gun, but not a common one in production at any real scale where you'd have a replica in the first place. InnoDB tables really should always have primary keys, and there are various ways to ensure that happens (sql_require_primary_key option, generated invisible primary key option, external linters, etc).

That's largely a fantasy in the NYC metro area as well. Unless you're talking about a tiny condo, and/or your office is extremely close to a major transit hub.

NATURAL JOIN is actually in the SQL standard; it's not specific to MySQL.

I'm not aware of any databases that allow UNION to take table names directly, although in many cases you can use the TABLE keyword as a shortcut for "SELECT * FROM".

My sense is that a lot of this activity isn't even legitimate use. As one example: my company has a GitHub app, and last night some bot added my app to 1700 repos. Then the bot immediately started rapid-firing commits which each affected hundreds of files, triggering a deluge of GitHub webhooks to my servers.

The repo names all matched other GitHub apps, so my sense is this bot had added 1700 GitHub apps to 1700 repos, with that number rapidly increasing at the upper bound of whatever GitHub's rate limit is.

My systems caught it quickly and auto-booted the bot, but the whole situation is ridiculous.

Unless I'm missing something, your linked comments seem to be responding only to the title of the article, without addressing any of the actual points being made in the body of the article?