Ways to shoot yourself in the foot with Postgres
291–300 of 329 posts
Re: Ways to shoot yourself in the foot with Postgres
#292Re: Ways to shoot yourself in the foot with Postgres
#293Re: Ways to shoot yourself in the foot with Postgres
#294Re: Ways to shoot yourself in the foot with Postgres
#295Re: Ways to shoot yourself in the foot with Postgres
#296Re: Ways to shoot yourself in the foot with Postgres
#297The two biggest ones imo were not mentioned: 1. Contrary to popular belief, Postgres isn't fully ACID (specifically the "I") with the default isolation mode. For example, selecting the sum of a column then inserting conditionally on that creates a race condition. Serializable mode is fully isolated, but it has many caveats and shouldn't be used often, so you should instead become familiar with what's isolated and wha…
> it has many caveats and shouldn't be used often I’d argue it isn’t used enough given its isolation advantages
Spanner and some other DBMSs are fully serializable always. They do a better job of that than Postgres, I guess cause they focus on it, but they're still a lot slower in the end.
What would be cool is some extension to watch your non-serializable transactions for concurrency anomalies like 1% of the time and use that tiny sample to alert you of race conditions. Like a thread sanitizer does for code. Does that exist??