In article [EMAIL PROTECTED],
Alex Adriaanse [EMAIL PROTECTED] writes:
Thanks for the input everyone. I think Harald's approach will work
well...
I'm not so sure anymore :-(
Consider something like that:
UPDATE tbl SET col1 = 1 WHERE col2 = 1;
UPDATE tbl SET col1 = 2 WHERE col2 = 1;
with
Harald Fuchs wrote:
In article [EMAIL PROTECTED],
Alex Adriaanse [EMAIL PROTECTED] writes:
Thanks for the input everyone. I think Harald's approach will work
well...
I'm not so sure anymore :-(
Consider something like that:
UPDATE tbl SET col1 = 1 WHERE col2 = 1;
UPDATE tbl SET col1 = 2
Thanks for the input everyone. I think Harald's approach will work
well, so I'm planning on doing what he suggested, with a few
modifications. I think I can still use a sequence-backed INTEGER rather
than TIMESTAMP, and have the trigger that sets the revision to NULL also
NOTIFY the daemon
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
Qingqing Zhou wrote:
Alex Adriaanse [EMAIL PROTECTED] writes
This seems to work, except there exists a race condition. Consider the
following series of events (in chronological order):
1. Initially, in the codes table there's a row with id=1, revision=1,
and a row with id=2, revision=2
In article [EMAIL PROTECTED],
Alex Adriaanse [EMAIL PROTECTED] writes:
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?
How about the following:
Alex Adriaanse [EMAIL PROTECTED] 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
[I've tried to send this message to pgsql-general several times now,
but even though I'm subscribed to it I never saw the message show up
in the mailing list, so I'm trying to send it from a different account
now. If you get several copies of this message, I apologize.]
I'm working on an
I'm working on an application where we have a central database server
and a bunch of clients that are disconnected most of the time, need to
maintain a local copy of the central database. The client databases are
based on One$DB since it has to be lightweight. The client does not
access the
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
Alex Adriaanse [EMAIL PROTECTED] writes
This seems to work, except there exists a race condition. Consider the
following series of events (in chronological order):
1. Initially, in the codes table there's a row with id=1, revision=1,
and a row with id=2, revision=2
2. Client A
11 matches
Mail list logo
