Re: Tracking row updates
От | Qingqing Zhou |
---|---|
Тема | Re: Tracking row updates |
Дата | |
Msg-id | d1nsjb$29pn$1@news.hub.org обсуждение исходный текст |
Ответ на | Tracking row updates (Alex Adriaanse <alex.adriaanse@gmail.com>) |
Список | pgsql-general |
"Alex Adriaanse" <alex@alexandcarmen.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
В списке pgsql-general по дате отправления: