marsovo

Joined 2 years ago

Karma

Submissions

Member since

Jul 7

Recent submissions

This sounds exactly like what people were saying right up to February 2022: it doesn't make sense, Russia won't invade Ukraine, Russia has enough land, it is geopolitical suicide. And yet, here we are!

And does it really seem like the USA is going to come to the rescue if Russia pushes into the Baltics? Heck at this point they may very well use the distraction to invade Greenland.

So what's the deterrent but for Europe to buy its own umbrella?

Comment · 1 year ago

When it was raining yesterday, and people with weather experience say "it might rain tomorrow", do you insist umbrellas should be left at home because it's just speculation?

Except in this scenario it's still raining as we speak. What data do you have that Russia will stop?

Comment · 1 year ago

Is there data in 2021 that would have led you to think Russia would attempt an outright invasion of Ukraine?

Is it really so outlandish to think that Russian irredentism[0] will continue?

Food for thought from 2014(!): https://youtu.be/HLAzeHnNgR8

[0]: https://en.wikipedia.org/wiki/Russian_irredentism

Comment · 1 year ago

Macroeconomics is very different from microeconomics. Your spending is my income and my spending is your income. If the government spends a dollar, where does it go?

Presumably it goes to some sort of goods and services. The employees pay income taxes. The businesses pay corporate taxes. And so on.

Similarly, when a business lays off 10,000 people, it's not their problem anymore. Whereas from a macroeconomic policy perspective, "everybody" is the government's responsibility.

Comment · 1 year ago

I see what you mean, but ACID is a fairly foundational expectation for SQL transactions (D being the relevant feature here)

That being said, my background is primarily Microsoft SQL more than Postgres. As such I'm occasionally bemused at the sort-of monoculture here around Postgres, where if Postgres doesn't have it, it may as well not exist*.

And so it is in this case (the DELAYED_DURABILITY documentation I linked above). Alas, this doesn't seem to be something I see in standard SQL, so indeed, as you say, it's too bad that the standard doesn't provide for relaxing the rules.

> The repeated use of a write request followed by a flush request may be detrimental to performance and will increase traffic on the I/O bus.

> Prior to the Linux Kernel 4.18 updates, Linux could use Fua but only for the file system journaling writes and not data writes.

> If your system supports Fua and you have the Linux Kernel 4.18 or newer updates, you can enable SQL Server trace flag -T3979 and use /opt/mssql/bin/mssql-conf set control.alternatewritethrough 0. SQL Server will use Fua write behavior patterns instead of Forced Flush. File systems supporting optimized Fua align SQL Server on Linux with SQL Server on Windows behavior and performance.

*I think performance of CTEs/Views is another topic where I noticed it, where it was just taken as given that they can hurt performance, whereas in T-SQL they are simply equivalent to subqueries

Comment · 1 year ago

I looked into this some more. There are other ways than explicit fsync. See this blurb on FUA (which basically treats the I/O as write-through)

https://techcommunity.microsoft.com/blog/sqlserver/sql-serve...

Comment · 1 year ago

I'm not sure we're using the same terminology. Committed means the transaction has been hardened to disk. That's the D in ACID.

Otherwise, is the suggestion that there be an artificial delay to allow other transactions to piggyback before returning success on commit 1?

Should that be a default? (That was the context of this thread)

Comment · 1 year ago

Sure, but now when transaction 1 is "committed", it isn't actually guaranteed to be there in the face of interruption. That's a big change to the default behavior...

Comment · 1 year ago

Sure, but the comment I responded to was lamenting that the commits are not asynchronous by default. The documentation I linked to was all about the considerations and behavior for asynchronous commits.

Comment · 1 year ago

How would that work without risking loss of committed transactions?

> Fully durable transaction commits are synchronous and report a commit as successful and return control to the client only after the log records for the transaction are written to disk. Delayed durable transaction commits are asynchronous and report a commit as successful before the log records for the transaction are written to disk. Writing the transaction log entries to disk is required for a transaction to be durable. Delayed durable transactions become durable when the transaction log entries are flushed to disk.

https://learn.microsoft.com/en-us/sql/relational-databases/l...

Comment · 1 year ago

More context on the external tank: https://archive.is/2017.03.30-030831/https://www.nasa.gov/mi...

> The common soda can, a marvel of mass production, is 94% soda and 6% can by mass. Compare that to the external tank for the Space Shuttle at 96% propellant and thus, 4% structure. The external tank, big enough inside to hold a barn dance, contains cryogenic fluids at 20 degrees above absolute zero (0 Kelvin), pressurized to 60 pounds per square inch, (for a tank this size, such pressure represents a huge amount of stored energy) and can withstand 3gs while pumping out propellant at 1.5 metric tons per second. The level of engineering knowledge behind such a device in our time is every bit as amazing and cutting-edge as the construction of the pyramids was for their time.

Comment · 1 year ago

PHP has grown up but in its wild youth was notorious for such gems as mysql_escape_string vs mysql_real_escape_string, rather than proper parameterization

It's not so much about Turing as it is libraries and patterns

After all, as I understand it this very issue was caused by escaping SQL rather than parameterizing it