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



---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Reply via email to