On 3/13/13 7:10 PM, Ants Aasma wrote:
On Thu, Mar 14, 2013 at 1:51 AM, Jim Nasby wrote:
On 3/12/13 9:10 AM, Ants Aasma wrote:
I have a feeling this is an increasingly widespread pattern with a
proliferation of mobile devices that need syncing.
If you're doing that with timestamps you're asking for a slew of problems,
not all of which can be solved by just adding some random amount of fluff to
your criteria. A queue-based solution is often a more robust solution, even
if it is harder to implement.
Do you know of anything else besides the obvious issues with having to
use one clocksource and ensure that it produces monotonic timestamps?
Those issues aren't enough? :)
My first reaction was also that this is what queues are meant for, but
the proposed solution seems to work surprisingly well. Unless you can
point at some glaring hole that I'm missing I would say that it is
good enough for a rather wide range of syncing problems.
It depends on how critical it is not to miss events. Timestamps in tables are always taken before transaction commit, so you can sometimes have a significant delay. You have to make certain the timestamp can't be changed, and that rows can't be deleted. It's also tricky to make certain you don't see any events twice.

Given all that, and how easy PgQ is to use, I don't understand why anyone would go with timestamps...
Jim C. Nasby, Data Architect jim@nasby.net
512.569.9461 (cell) http://jim.nasby.net

Search Discussions

Discussion Posts


Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 7 of 7 | next ›
Discussion Overview
grouppgsql-hackers @
postedFeb 2, '13 at 10:06a
activeMay 26, '13 at 4:01p



site design / logo © 2021 Grokbase