Transactions and Concurrency in PostgreSQL
doadm-notes.blogspot.com
Transactions and Concurrency in PostgreSQL
1–10 of 17 posts
Re: Transactions and Concurrency in PostgreSQL
#2[flagged]
Re: Transactions and Concurrency in PostgreSQL
#3[flagged]
"Security"? This has nothing to do with security. Also, it's not great to pollute technical forums with more ChatGPT-generated content when it would be more useful for domain experts to contribute their own knowledge.
Re: Transactions and Concurrency in PostgreSQL
#4[flagged]
"Security"? This has nothing to do with security. Also, it's not great to pollute technical forums with more ChatGPT-generated content when it would be more useful for domain experts to contribute their own knowledge.
I personally find it refreshing to read an example that is not "A deposits $10, B withdraws $10".
Re: Transactions and Concurrency in PostgreSQL
#5[flagged]
This is not a very good analogy I think. Serializable reads like a table or database level lock, but that is not at all what it is.
Re: Transactions and Concurrency in PostgreSQL
#6Earlier quoted context omitted.
"Security"? This has nothing to do with security. Also, it's not great to pollute technical forums with more ChatGPT-generated content when it would be more useful for domain experts to contribute their own knowledge.
I personally find it refreshing to read an example that is not "A deposits $10, B withdraws $10".
That's becuse this example explains pretty much none of the phenomena that is a result of the isolation levels.
Re: Transactions and Concurrency in PostgreSQL
#7There's no mention of the REPEATABLE READ isolation level, though it mentions that READ COMMITTED can exhibit non-repeatable read behaviour. Here's the docs:
[0] https://www.postgresql.org/docs/current/transaction-iso.html
Re: Transactions and Concurrency in PostgreSQL
#8[flagged]
"Security"? This has nothing to do with security. Also, it's not great to pollute technical forums with more ChatGPT-generated content when it would be more useful for domain experts to contribute their own knowledge.
I don't get your comment, to be quite honest.
Besides, I don't like 3rd party A.I. services: the content that you see, is the content that I wrote.
And this comment of yours seems more of something to offend than to contribute.
I feel bad for you.
Re: Transactions and Concurrency in PostgreSQL
#9Earlier quoted context omitted.
I personally find it refreshing to read an example that is not "A deposits $10, B withdraws $10".
That's becuse this example explains pretty much none of the phenomena that is a result of the isolation levels.
I'm sorry, but you're wrong...
In Postgresql, the default ISOLATION LEVEL is "READ COMMITTED", which by standard, allows "NON-REPEATABLE READ" phenomena.
When Transaction on the LEFT is COMMITTED (adding 100 to balance), the Transaction on the RIGHT will add 400 to a balance of 1100, and not to a balance of 1000 (reading NON-REPEATED value).
You can do better than leaving this kind of comment that does not contribute in anything.
Have good weekend.
Re: Transactions and Concurrency in PostgreSQL
#10Earlier quoted context omitted.
"Security"? This has nothing to do with security. Also, it's not great to pollute technical forums with more ChatGPT-generated content when it would be more useful for domain experts to contribute their own knowledge.
I personally find it refreshing to read an example that is not "A deposits $10, B withdraws $10".
Me too, thanks. Would be nice if you can share some articles that you wrote regarding the matter, so I can have more inspiration. Looking forward to read them and learn from different examples and not the same "boiler plate" example that you can find on any DBMS documentation.