Re: Doubt in mvcc

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, <folarte(at)peoplecall(dot)com>
wrote:

> Rama:
>
> On Mon, Jul 13, 2020 at 9:52 AM Rama Krishnan <raghuldrag(at)gmail(dot)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.
>