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:
* Use a TIMESTAMP rather than a SERIAL
* Set this timestamp to NULL in your INSERT/UPDATE trigger
* Use a cron job to set the timestamp to current_timestamp when it's NULL
This way the client would lag behind somewhat, depending on the cron
job frequency, but it should not miss a change.
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
