Re: Tracking row updates

From: "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Tracking row updates
Date: 2005-03-22 01:27:42
Message-ID: d1nsjb$29pn$1@news.hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


"Alex Adriaanse" <alex(at)alexandcarmen(dot)com> writes
> Applying this analogy to our database, wouldn't that require a
> table-level lock during a CVS-like commit (which would mean locking the
> table, getting the revision number, updating the row(s), and committing
> the transaction)?
>

You may have a look at how CVS works and decide it. Note the difference is
that CVS manages the files and versions, and seems you just manage the
versions?

Another way is to change the logic - try to submit the update together.
Think the bank-transfer example we always used in describing transaction's
atomic property, which shares something common in your case. We fold the
logic of reduce some money and add some money together, so no matter how
many concurrent transfer is on the target account, it is guarantteed no race
condition, since the "serializable" property assures that.

Regards,
Qingqing

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Carlos Moreno 2005-03-22 03:31:27 Re: Encoding-related errors when moving from 7.3 to 8.0.1
Previous Message Doug McNaught 2005-03-22 01:02:30 Re: Problem connecting to postmaster