> each of your webheads has its own clock. Use the database clock! Yes, for consistency you should use the database clock by embedding the calls to `now()` or

> each of your webheads has its own clock. Use the database clock! Yes, for consistency you should use the database clock by embedding the calls to `now()` or similar in the query instead of generating it on the client. But it's not sufficient to use these timestamps for synchronization. The problem is that these timestamps are generated at the start of the transaction, not the end of the transaction when it commits. So if you poll a table and filter for recent timestamps, you'll miss some from transactions that are committing out of order. You can add a fudge factor like querying back an extra few minutes and removing the duplicates, but some transactions will take longer than a few minutes. There's no upper bound to how long a transaction can take in postgresql, and there's a lot of waste in querying too far back. This approach doesn't work if you care about correctness or efficiency.