I think that would greatly decrease the chances of a race condition
occurring, but I don't think it'd solve it. What if 150 other revisions
occur between a row update and its corresponding commit?
Alex
Vincent Hikida wrote:
>>
>> To fetch all updates since the last synchronization, the client would
>> calculated a value for $lastrevision by running this query on its
>> local database:
>> SELECT max(revision) AS lastrevision FROM codes;
>>
>> It would then fetch all updated rows by running this query against
>> the server:
>> SELECT * FROM codes WHERE revision > $lastrevision;
>>
>
> How about
>
> SELECT * FROM codes WHERE revision > $lastrevision - 100
>
> You could use another number other than 100. As you said, the client
> can handle duplicates.
>
> Vincent
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if
> your
> joining column's datatypes do not match
