It very clearly did not mean “go and hack third parties” though

Using arrow is cool, but grpc seems like a more natural fit than arrow IPC and would give you the same benefits.

So who is this for?

> Of course we need strong sandboxing. We also need to secure the services it can reach, the tools it can invoke

That’s… the sandbox. The sandbox includes everything in the sandbox.

> So is it as easy as just putting it in a sandbox? No, it’s not. But I do believe it is tractable across three dimensions

Those 3 dimensions are sandboxing, alignment and monitoring.

I’d suggest that monitoring is a part of any sandbox. That leaves “the sandbox” and “trying to get the model to not escape the sandbox”?

You should just use protobuf, far before you get to this step

exactly: already has data. It’s not the statement that’s unsafe, it’s the size of the table. That’s what all pattern matching migration checkers get wrong.

You might be releasing a new feature gradually and you realised your schema is slightly wrong and want to alter a column type. You’ve got some tiny volume of data in one production cluster. Is it safe?

A pseudo rule determining the safety for any arbitrary migration that causes a rewrite could be:

   smt.is_rewrite and tbl.size < 10MB

No: on your 10TB orders table

To accurately model migration safety you don’t really care about the statement: you care about the effects (locks, rewrites, additions, etc). That’s what is safe or unsafe.

The problem is that some migration safety depends on the state of the database, which isn’t represented in the DDL statement alone. For example, altering a column type is either a no-op or an exclusive locked table rewrite depending on the original type of the column.

There are other footguns that can happen if the column you’re altering is a foreign key, where multiple tables can be locked.

I went down a rabbit hole a few years ago and built a system[1] to introspect a given migration against a live schema, and actually let Postgres tell you what it’s doing[2].

It would be great to have better built-in support for this (EXPLAIN for DDL statements?), but this direction feels safer and more accurate than static rulesets.

Safety also depends on the size/activity of a table being altered (i.e rewriting an empty table is fine). Having an accurate representation of the locks and actions performed by the database lets you integrate with production metrics to actually determine real-world safety across a fleet of databases, rather than guessing.

1. https://github.com/orf/locksmith

2. https://github.com/orf/locksmith/blob/f8798c6ee92bfae10d416c...

“the purpose of a system is what it does”

Your legacy codebase generates ~300 billion a year?

Comments URL: https://news.ycombinator.com/item?id=49813083

Points: 1

# Comments: 0

Tl;dr - a concurrency bug / race condition

> ZCode, the GLM coding agent, silently uploads your Git history

https://news.ycombinator.com/item?id=49752422

I.e it’s unclear how this works with per-request billing - if I set a budget of $20, then immediately spam $40 worth of S3 GET requests, will 50% of those requests be blocked or will I be charged $40?

I doubt they’ve added a globally consistent billing/charge counter to the S3 read path, so either I get charged $40 or AWS eats the additional $20.

What do you think the second, third and fourth order effects of this would be for you?

What new problems, closer to home, would arise?

All engineers are equal, however some engineers are more equal than others?