From: | Alex Adriaanse <alex(at)alexandcarmen(dot)com> |
---|---|
To: | Vincent Hikida <vhikida(at)inreach(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Tracking row updates - race condition |
Date: | 2005-03-21 17:52:15 |
Message-ID: | 423F09CF.2030008@alexandcarmen.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Alex Adriaanse | 2005-03-21 18:02:20 | Re: Tracking row updates |
Previous Message | Eric Parusel | 2005-03-21 17:52:01 | how do I clear a page, or set an item in a page to 'free'? |