Re: Tracking row updates - race condition

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

In response to

Responses

Browse pgsql-general by date

  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'?