On Thu, 26 Nov 2020 19:13:53 -0500
Mohamed Wael Khobalatte <mkhobalatte@grubhub.com> wrote:
> >
> > Thus, what does SERIALIZABLE READ ONLY achieve that REPEATABLE READ READ
> > ONLY does not? And what is SERIALIZABLE READ ONLY DEFERRABLE for?
> >
>
> There is a nice walkthrough of the "control" and "batches/details" scenario
> mentioned in the docs, you can find it in the wiki,
> <https://wiki.postgresql.org/wiki/SSI#Deposit_Report> and I think it
> explains the difference well.
Thank you, it helped me a lot.
If there are two REPEATABLE READ READ WRITE transactions, which do *not* require SERIALIZABLE isolation, there could
stillbe a third READ ONLY transaction, which has stricter requirements on isolation when retrieving data. SERIALIZABLE
READONLY will fail under certain circumstances in which case the retrieved information should be deemed void and
re-requestedin a new transaction in order to fit the extra requirements on isolation of the read-only transaction.
Then "DEFERRABLE" makes sense too, as it will make the third transaction block for a certain time instead of risking
cancellation.
Thanks
Jan