Thanks for clarifying Jonathan. I agree with your example.
It seems we have now moved into discussing specific requirements/semantics
for an interactive transaction implementation. Which is interesting, but
beyond what I will have time to think about tonight. At least off the top
of my head I can'
... which is a long way of saying, in postgresql those errors are there as
part of checking for correctness -- when you see them it means you did not
ask for the appropriate locks. It's not expected that you should write
try/catch/retry loops to work around this.
On Thu, Oct 14, 2021 at 11:13 AM
[Moving followup here from the other thread]
I think there is in fact a difference here.
Consider a workload consisting of two clients. One of them is submitting a
stream of TPC-C new order transactions (new order client = NOC), and the
other is performing a simple increment of district next or
On Wed, Oct 13, 2021 at 3:38 PM bened...@apache.org
wrote:
> It may have been lost in the back and forth (there’s been a lot of
> emails), but I outlined an approach for READ COMMITTED (and SERIALIZABLE)
> read isolation that does not require a WAN trip.
Yes, thank you. I knew I had read it but
> It seems like potentially every statement now needs to go through the Accord
> consensus
protocol, and this could become expensive, where my goal was to design the
simplest and most lightweight example thinkable. BUT for read-only Accord
transactions, where I specifically also don't care about s
