Hi Francisco, Still, I have a doubt as per your example both are trying to update the same tuple so it may produce two different copies right?
I read some blocks they mentioned drawback above two things It may lead to lost update also For example, two transactions are going to increase the amount on the same account by $100 . The first transaction reads the current value ($1000) and then the second transaction reads the same value. The first transaction increases the amount (this gives $1100) and writes this value. The second transaction acts the same way: it gets the same $1100 and writes this value. As a result, the customer lost $100. Will u please provide more details Serialize is the solution to this issue. On Mon, 13 Jul, 2020, 14:12 Francisco Olarte, <fola...@peoplecall.com> wrote: > Rama: > > On Mon, Jul 13, 2020 at 9:52 AM Rama Krishnan <raghuld...@gmail.com> > wrote: > > I m preparing for interview one of the recruiter asked me mvcc drawbacks > as i told due to mvcc it use more space and need to perform maintenance > activity. > > Another one is the same data causes an update conflict because two > different transactions can update the same version of the row. > > he told its wrong, kindly tell me will you please tell me its correct > or wrong? > > I'm not sure I understand your question too well, you may want to > refresh/expand. > > One interpretation is, on a pure MVCC contest, two transactions, say 5 > and 6, could try to update a tuple valid for [1,) and end up > generating two new tuples, [5,), [6,) and closing the original at > either [1,5) or [1,6) . > > That's why MVCC is just a piece, locking is other. On a MVCC the > tuples are locked while a transaction manipulates them. Other > transactions may read them, which is why readers do not block writers, > but two updates on the same tuple serialize. > > > Francisco Olarte. >
