No person shall circumvent a technological measure that effectively controls access to a work protected under this title.
https://www.law.cornell.edu/uscode/text/17/1201
Can the emulators remove the circumvention code to avoid the DMCA takedown?
INSERT INTO foo (bar) (SELECT max(bar) + 1 FROM foo);
can insert duplicate `bar` values when run concurrently using the default mode, since one xact might not see the new max value created by the other. You might think adding a UNIQUE index would cause the "losing" xact to get constraint errors, but instead both xacts succeed and no longer have a race condition.This is not true. What happens is that the (sub)transaction that loses the race to the index is aborted:
=# INSERT INTO foo (bar) (SELECT max(bar) + 1 FROM foo);
ERROR: duplicate key value violates unique constraint "foo_bar_idx"
DETAIL: Key (bar)=(2) already exists.
Imagine booting your computer and having to give an email to login offline.
Then you click on a link and it auto opens through edge, "DO YOU WANT TO IMPORT AND GIVE US YOUR PRIVACY?"
Or imagine you try to uninstall some microsoft app, it doesn't let you, you try to remove it thorugh the registry but the top 10 results on google are outdated with a different windows.
2 hours later, your computer reboots automatically during a windows update. Everything is turned off, you are dealing with autosaves, you re-open your browser and tons of tabs open slowly.
Finally you save some files in your local documents pictures folder, and start getting nagged about not having enough space in OneDrive. No big deal I don't use that. Lets delete OneDrive. Oh my god I lost all of my files.
As much as I hate what modern Windows has become, this is not actually true. If you know the correct sequence of clicks you can avoid this. Not defending this bullshit, though.
UPDATE orders SET deletion_timestamp = CURRENT_TIMESTAMP() WHERE deletion_timestamp IS NULL
1. Transaction A starts, its before trigger fires, Row 1 has its updated_at timestamp set to 2023-09-22 12:00:01.
2. Transaction B starts a moment later, its before trigger fires, Row 2 has its updated_at timestamp set to 2023-09-22 12:00:02.
3. Transaction B commits successfully.
4. Polling query runs, sees Row 2 as the latest change, and updates its cursor to 2023-09-22 12:00:02.
5. Transaction A then commits successfully.
A simple way to avoid this issue is to not poll close to real-time, as the order is eventually consistent.
Perhaps a more robust suggestion would be to use a sequence? Imagine a new column, `updated_at_idx`, that incremented every time a row was changed.
This wouldn't be such a problem, since of course you can just "choose" to not use pointer- or interface-typed fields in "your" structs, but as soon as serialization, databases, or other people's APIs are involved, you don't have that "choice" anymore.
In the same vein, being unable to write e.g. &true or &"foo" is annoying too. If I can write &struct{...} why can't I write &true?